Personal Wireless Navigation System

ABSTRACT

A personal wireless navigation system operable on wireless phone devices provides a platform for empowering a merchant-paid search. Performance of a navigation functionality in a personal wireless navigation system is higher and more comparable and competitive with portable navigation devices and in-car navigation systems, and the search capability is comparable and competitive with the most popular web search engines. A user interface (UI) and look and feel of the personal wireless navigation system is provided which is enhanced so that users do not simply want to use the product—they covet it. The personal wireless navigation system may be constructed such that a subset of it with fewer features and functions can be productized, marketed and deployed to users.

The present application claims priority from U.S. Provisional No.61/344,091, filed May 21, 2010 to Sheha et al., entitled “PersonalWireless Navigation System”; and from U.S. Provisional No. 61/344,245,filed Jun. 18, 2010 to Sheha et al., entitled “Personal WirelessNavigation System”, the entirety of both of which are explicitlyincorporated herein by reference.

BACKGROUND OF THE INVENTION Field of the Invention

This invention concerns communication systems and methods, but morespecifically, the invention relates to a server-based personal wirelessnavigation system with a user interface on a wireless phone.

SUMMARY OF THE INVENTION

In accordance with the principles of the present invention, a carouseluser interface for a personal wireless device comprises acircular-depicted carousel comprising a plurality of carousel pages ofinformation sources. The carousel is visually rotated about a center.The carousel continuously rotates sequentially the plurality of carouselpages of information sources, and repeats the rotation in a same orderon subsequent full rotations of the carousel. The carousel furthercomprises at least one carousel page of changing information thatchanges upon each full rotation of the carousel.

A method of displaying a plurality of pages of information on a personalwireless device comprises assembling the plurality of carousel pages ofinformation visually into a carousel that rotates about a center point.The plurality of carousel pages of information display informationreadable from a direction outside a perimeter of the carousel. A contentof one of the plurality of carousel pages of information is changedafter each rotation of the carousel beyond when the one of the pluralityof carousel pages of information is displayed front and center. Thecarousel is rotated in a clockwise or counter-clockwise direction byhand gestures on a touch screen of the personal wireless device.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention become apparent tothose skilled in the art from the following description with referenceto the drawings:

FIG. 1 shows an exemplary overall system architecture of a NAVBuilderplatform, in accordance with the principles of the present invention.

FIG. 2 shows an exemplary client architecture diagram of an AtlasBookapplication, in accordance with the principles of the present invention.

FIG. 3 shows exemplary NAVBuilder client architecture, in accordancewith the principles of the present invention.

FIG. 4 shows exemplary NAVBuilder inside client architecture, inaccordance with the principles of the present invention.

FIG. 5 shows another exemplary embodiment of NAVBuilder clientarchitecture, in accordance with the principles of the presentinvention.

FIG. 6 shows an exemplary navigation interaction, in accordance with theprinciples of the present invention.

FIG. 7 shows additional sample navigation interaction, in accordancewith the principles of the present invention.

FIG. 8 shows yet additional sample navigation interaction, in accordancewith the principles of the present invention.

FIG. 9 shows an exemplary navigation session timeline, in accordancewith the principles of the present invention.

FIG. 10 shows a high level architecture diagram, in accordance with theprinciples of the present invention.

FIG. 11 depicts redundancy of the NAVBuilder, in accordance with theprinciples of the present invention.

FIG. 12 shows another high level architecture diagram, in accordancewith the principles of the present invention.

FIG. 13 shows exemplary server components, in accordance with theprinciples of the present invention.

FIG. 14 shows an exemplary physical database layout, in accordance withthe principles of the present invention.

FIG. 15 shows a Map Tile Server, in accordance with the principles ofthe present invention.

FIG. 16 shows detailed architecture, in accordance with the principlesof the present invention.

FIG. 17 shows a top level user interface flow for the carousel, inaccordance with the principles of the present invention.

FIG. 18 shows exemplary user interface flow for application launch ofthe AtlasBook Navigator, in accordance with the principles of thepresent invention.

FIG. 19 shows exemplary user interface flow for voice recognition forSay Business, in accordance with the principles of the presentinvention.

FIG. 20 shows point of entry states, in accordance with the principlesof the present invention.

FIG. 21 shows point of entry states for non-touch screen embodiments, inaccordance with the principles of the present invention.

FIG. 22 shows exemplary user interface flow for landing zones, inaccordance with the principles of the present invention.

FIG. 23 shows exemplary user interface top level flow for locationselection, in accordance with the principles of the present invention.

FIG. 24 shows exemplary user interface flow for non-touch screenlocation wizard operation, in accordance with the principles of thepresent invention.

FIG. 25 shows exemplary user interface flow for touch screen locationwizard operation, in accordance with the principles of the presentinvention.

FIG. 26 shows exemplary user interface flow for entry and acceptance ofa license key, in accordance with the principles of the presentinvention.

FIG. 27 shows exemplary user interface flow relating to a user's accountinformation, in accordance with the principles of the present invention.

FIG. 28 shows exemplary user interface flow relating to launch ofAtlasBook Navigator from Contacts, in accordance with the principles ofthe present invention.

FIG. 29 shows exemplary user interface flow relating to launch ofAtlasBook Navigator from Calendar, in accordance with the principles ofthe present invention.

FIG. 30 shows exemplary user interface flow relating to synchronizationof Events, in accordance with the principles of the present invention.

FIG. 31 shows exemplary user interface flow relating to please waitscreens, in accordance with the principles of the present invention.

FIG. 32 shows exemplary user interface flow relating to voice navigationfor the feature Say Airport, in accordance with the principles of thepresent invention.

FIG. 33 shows exemplary user interface flow relating to voice navigationfor the feature Say Address—Nuance, in accordance with the principles ofthe present invention.

FIG. 34 shows exemplary user interface flow relating to voice navigationfor the feature Say Address(Vlingo), in accordance with the principlesof the present invention.

FIG. 35 shows exemplary user interface flow relating to launch ofAtlasBook Navigator under a third party's trademark, in accordance withthe principles of the present invention.

FIG. 36 shows exemplary user interface flow relating to launch ofanother embodiment of AtlasBook Navigator, in accordance with theprinciples of the present invention.

FIG. 37 shows exemplary user interface flow relating to a clickableembodiment of the Carousel, in accordance with the principles of thepresent invention.

FIG. 38 shows exemplary user interface flow for first time through (FTT)provisioning of the AtlasBook Navigator, in accordance with theprinciples of the present invention.

FIG. 39 shows exemplary user interface flow for SPG Storm/Curve2 typedevices, in accordance with the principles of the present invention.

FIG. 40 shows exemplary user interface flow for SPG Calgary/Palm typedevices, in accordance with the principles of the present invention.

FIG. 41 shows exemplary user interface flow for launch of an alternateembodiment of the AtlasBook Navigator, in accordance with the principlesof the present invention.

FIG. 42 shows exemplary user interface flow for first time through (FTT)purchase of a license for use of an AtlasBook Navigator product, inaccordance with the principles of the present invention.

FIG. 43 shows exemplary user interface flow for upgrade of the AtlasBookNavigator product & services from a map view, in accordance with theprinciples of the present invention.

FIG. 44 shows exemplary user interface flow for operation of a locationwizard for selecting location, in accordance with the principles of thepresent invention.

FIG. 45 shows exemplary user interface flow for working through a user'saccount information, in accordance with the principles of the presentinvention.

FIG. 46 shows exemplary user interface flow in a Carousel view of theAtlasBook Navigator, in accordance with the principles of the presentinvention.

FIG. 47 shows a minimum device list for the form factors for AB and thepersonal wireless navigation system, in accordance with the principlesof the present invention.

FIG. 48 illustrates one avenue for purchasing the personal wirelessnavigation system, in accordance with the principles of the presentinvention.

FIG. 49 illustrates an exemplary flow chart for a billing process, inaccordance with the principles of the present invention.

FIGS. 50A and 50B show an exemplary sequence when a user speaks acomplete or partial address, the personal wireless navigation systemprocesses the single utterance as a destination, and displays theprocessed text in the appropriate address fields, in accordance with theprinciples of the present invention.

FIG. 51 shows when the user speaks a POI category or name, the personalwireless navigation system processes the spoken word and displays theprocessed text in a ‘What’ field.

FIGS. 52A and 52B show an exemplary “please wait” display area, in thegiven embodiment a gray area in the screen, recognized by the inventorsherein to be a preferred area where an advertisement or other paid-forinformation may be placed within the screen.

FIG. 53 shows an exemplary “Please Wait” screen with premium placementadvertising.

FIGS. 54A and 54B show when a geo poke or response to a geo-poke isreceived, it preferably includes brief information or a flag identifyingthe brand of the personal wireless navigation system to the receiver,such that the receiver knows that they are getting poked by someone whohas a branded version of the personal wireless navigation system ontheir phone.

FIG. 55 shows that when a geo poke or response to a geo-poke isreceived, it includes brief information or a flag identifying the brandof the personal wireless navigation system to the receiver; such thatthe receiver knows that they are getting poked by someone who has abranded version of the personal wireless navigation system on theirphone.

FIG. 56 shows an exemplary touch screen device where a user can click onan icon, and details relating to the clicked-on POI are displayed, inaccordance with the principles of the present invention.

FIG. 57 shows an exemplary enhanced trip summary screen, in accordancewith the principles of the present invention.

FIG. 58 shows a personal wireless navigation system displaying new mapinformation as it becomes available, in accordance with the principlesof the present invention.

FIG. 59 shows a table identifying where in the application users canchange specific options, and whether the change will be permanent (i.e.,=Sticky) or temporary (X=non-sticky).

FIG. 60 shows the Zoom slider using a touch and drag gesture, inaccordance with the principles of the present invention.

FIG. 61 shows the user interface (UI) flow for a MOVIE . . .RESULTS/MOVIE DETAILS. Horizontal Swipe sequence: DOWN, GESTUREsequence.

FIG. 62 shows dragging up and down support use instead of a scroll bar.The personal wireless navigation system uses a floating bar (with notrack and no arrows at the top or bottom of the track) that illustratesproximity to either end of any list; e.g., search result list, RecentSearches list, etc.

FIG. 63A shows a box-out transition, in accordance with the principlesof the present invention.

FIG. 63B shows a box-in transition, in accordance with the principles ofthe present invention.

FIG. 63C shows a slide-in/slide-out transition, e.g., used in responseto moving from one screen and moving from search details, in accordancewith the principles of the present invention.

FIG. 64 shows an example of LBS functions available as a menu optionwhen a user selects a contact within the “AddressBook” application, inaccordance with the principles of the present invention.

FIG. 65 shows a pop-up displaying address fields for a contact.

FIG. 66 shows a main menu comprising four general frames, in accordancewith the principles of the present invention.

FIG. 67 is a table showing a menu of options when the user taps on themarker for the current location.

FIG. 68 is a table showing a menu of options when a user double taps onthe same spot on the map.

FIG. 69 shows a personal wireless navigation system expeditingspeech-to-text conversion by eliminating or reducing the wait time for afirst screen when a user speaks a business type, in accordance with theprinciples of the present invention.

FIG. 70 shows a user can tap on any POI to see a brief description ofthe POI.

FIG. 71 shows exemplary zoom levels, in accordance with the principlesof the present invention.

FIG. 72 shows an exemplary Tile Map architecture, in accordance with theprinciples of the present invention.

FIG. 73 shows a tile coordinate system dividing the map of the worldinto 2^(z) tiles where, z is zoom level, in accordance with theprinciples of the present invention.

FIG. 74 shows a map tile for z=9, x=88, y=204, size=256 (referencetile).

FIG. 75 shows Metatile enabled, x=88, y=204, z=8, size=256, with aregion to be cut from this meta tile to satisfy the request z=9, x=88,y=204, in accordance with the principles of the present invention.

FIG. 76 shows an exemplary call flow sequence to obtain the map from thetiled maps server.

FIG. 77 shows an overall functional block diagram of an exemplaryplatform taking the first approach, in accordance with the principles ofthe present invention.

FIG. 78 shows an exemplary flow of information from terminal to the webservice, and back, in accordance with the principles of the presentinvention.

FIG. 79 shows an exemplary traffic probe network, in accordance with theprinciples of the present invention.

FIG. 80 shows traffic probe and related components, in accordance withthe principles of the present invention.

FIG. 81 shows exemplary call flows when the application starts up andrequests initial settings from the server, in accordance with theprinciples of the present invention.

FIG. 82 shows exemplary call flow when the client requests MOTDs, andprobes the EULA for collecting probe data, in accordance with theprinciples of the present invention.

FIG. 83 shows exemplary call flows relevant to the use of UserPreferences to change the accept/decline status of the Probes EULA, inaccordance with the principles of the present invention.

FIG. 84 shows exemplary call flows relevant to GPS probe data collectedby the client which periodically sends it to the server for distributionto the various data collectors.

FIG. 85 shows an exemplary “U R Here!” area of a Heads-Up display, inaccordance with the principles of the present invention.

FIG. 86 shows an exemplary “Real-time Content Carousel” area of aHeads-Up display, in accordance with the principles of the presentinvention.

FIG. 87 shows an exemplary “Commands” area of a Heads-Up display, inaccordance with the principles of the present invention.

FIG. 88 shows exemplary alternative display modes, in accordance withthe principles of the present invention.

FIG. 89 shows an exemplary Carousel setup screen, in accordance with theprinciples of the present invention.

FIG. 90 shows a carousel display sequence, in accordance with theprinciples of the present invention.

FIG. 91 shows an exemplary Carousel Setup Screen enabling users to addadditional content in the Carousel, in accordance with the principles ofthe present invention.

FIG. 92 illustrates an exemplary model for displaying this content type,which is properly localized in accordance with the user's regionalsettings.

FIG. 93 shows an exemplary content screen displaying the name andlocation of the upcoming Next Meeting Alert (Time & Place) event that ison the user's calendar, such that the user can invoke an LBS action suchas ‘Go’, ‘Find’, ‘Share’, or ‘Map’.

FIGS. 94A-94C show an exemplary web interface Mock-up, in accordancewith the principles of the present invention.

FIG. 95 shows exemplary support for Enterprise definition, in accordancewith the principles of the present invention.

FIG. 96 shows presentation of Custom POIs to eligible/interested users,in accordance with the principles of the present invention.

FIG. 97 depicts a device screen for a user to select enterprise orinterest-specific POIs as a specific Category (SEARCH>CATEGORY), inaccordance with the principles of the present invention.

FIG. 98 shows that in this way the inventive navigation product avoidspotential problems of multiple duplicate listings by providing a“binary” selection capability that does not merge existing/other POIswith enterprise or interest-specific POIs.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

A personal wireless navigation system is provided, branded AtlasBookNavigator (ABN) version 5 (v5). It is the core platform for productscommercially available from TeleCommunication Systems, inc. inAnnapolis, M.D., including Verizon (VZ) Navigator v5, Telus Navigatorv5, Your Navigator v5, AAA Mobile v5, etc. The present inventorsdeveloped and launched the personal wireless navigation system onlimited devices per each suitable available platform (Windows Mobile,blackberry Java, Brew, J2ME, etc), and then ported the application todevice batches for each business partner.

AtlasBook (AB) v5 is the upgrade path for AtlasBook v4 North American,AtlasBook v4 European Edition, and AtlasBook v3 and v2.

A direct billing and distribution mechanism is also created forAtlasBook Navigator and selective brands independent of the carrier'sapplication shops.

The AtlasBook (AB) v5 personal wireless navigation system is a coreproduct that other brands are based on. The personal wireless navigationsystem is a platform for empowering a merchant-paid search.

Performance of a navigation functionality in the personal wirelessnavigation system is higher and more comparable and competitive with PNDand in-car navigation systems, and the search capability is comparableand competitive with the most popular web search engines. A userinterface (UI) and look and feel of the personal wireless navigationsystem is provided which is enhanced so that users do not simply want touse the product—they covet it.

Ideally the personal wireless navigation system is constructed such thata subset of it with fewer features and functions can be productized,marketed and deployed to users.

The general requirements of the AtlasBook v5 personal wirelessnavigation system include capacity planning, the available platformsthat it needs to support, and the time frame for launching it.

NAVBuilder Platform Architecture

FIG. 1 shows an exemplary overall system architecture of a NAVBuilderplatform, in accordance with the principles of the present invention.

FIG. 2 shows an exemplary client architecture diagram of an AtlasBookapplication, in accordance with the principles of the present invention.

FIG. 3 shows exemplary NAVBuilder client architecture, in accordancewith the principles of the present invention.

FIG. 4 shows exemplary NAVBuilder inside client architecture, inaccordance with the principles of the present invention.

FIG. 5 shows another exemplary embodiment of NAVBuilder clientarchitecture, in accordance with the principles of the presentinvention.

The purpose of the NAVBuilder client architecture is to provide a commoninterface for device and operating system (OS) services to enablecross-platform Core code. It is separated into three components: Coreservices, NAVBuilder services, and AtlasBook services. Preferablyimproper dependencies are controlled, with enforcement in the build.Preferably different packaging and distribution options are enabled.

All code is preferably cross-platform C or JAVA. Preferably only PALabstractions are used, and does not call device or library APIsdirectly. No #ifdefs or conditional code based on platform.

Core services provide basic utilities and services, not specific toproduct or functionality. Network features include generic networkrequest/reply handling, and protocol packing/unpacking (TPS).

NAVBuilder services provide application independent Geoservices. Itfeatures geocode, reverse geocode, local search (POI, movies, events,weather, traffic incidents). It also features map features such asstatic raster, raster tile, and vector tile. It includes staticdirections, optional navigation, and analytics.

AtlasBook services provide application specific services for theAtlasBook application. It preferably includes features such assubscription, filesets, synchronization, share, server message, ASR,profile (User Settings), and datastore.

Service Connector provides a thread-safe interface to NAVBuilder andAtlasBook services, and also provides support for cross-languagemarshalling.

The User Interface provides a consistent experience across all versionsof the application. Unified User Interface (UI) flow is provided withtouch and non-touch variations. The OS and platform specific variationsprovide pop-up menus, toolbars, footers and soft keys. The UserInterface is integrated with device applications such as Contacts andCalendar, and provides App2App APIs to support integration with otherapplications.

FIG. 6 shows an exemplary navigation interaction, in accordance with theprinciples of the present invention.

FIG. 7 shows additional sample navigation interaction, in accordancewith the principles of the present invention.

FIG. 8 shows yet additional sample navigation interaction, in accordancewith the principles of the present invention.

FIG. 9 shows an exemplary navigation session timeline, in accordancewith the principles of the present invention.

FIG. 10 shows a high level architecture diagram, in accordance with theprinciples of the present invention.

FIG. 11 depicts redundancy of the NAVBuilder, in accordance with theprinciples of the present invention.

FIG. 12 shows another high level architecture diagram, in accordancewith the principles of the present invention.

FIG. 13 shows exemplary server components, in accordance with theprinciples of the present invention.

Server components include Servlets, Master Servlet, Mux, and Service.The servlets are stateless worker processes that handle a single clientrequest. The master servlet spawns worker processes to handle a specifictype of client request (e.g., geocode). It manages servlet workers,providing both request queuing and flow-control. The Mux is an Edgegateway that manages client connections on a public listening port. Itis responsible for routing messages between servlets and clients:‘target name’|<message payload>. It provides a simple round-robin loadbalancing for distributed servlet workers. Service is any programrunning on the server that is not a servlet or mux.

Multiple database schemas use an assortment of technologies, includingOracle Real Application Clusters (RAC), PostgreSQL, and SQLite. Cachingis distributed to reduce load to the backend databases. A DB-proxydecouples critical features from potential database latency, A “DBBypass Mode” provides fault-tolerance.

The user database 652 shown in FIG. 13 maps client devices to userpreferences; supports recent/favorite places, messaging (e.g., PlaceMessages and MotD/OTA/EULA), and subscriptions.

The monitoring database 654 shown in FIG. 13 uses PostgreSQL. Everyclient transaction is recorded. Server metrics are recorded, and it isused for business intelligence. It preferably has operational alertingcapabilities, and permits non-intrusive debugging of run-time anomalies.

The traffic database 656 shown in FIG. 13 tracks in-progress clientnavigations for notification. In the disclosed embodiment the trafficdatabase 656 contains no traffic flow data, or traffic incident data.

A SearchBuilder database 658 shown in FIG. 13 stores dynamic searchdata, e.g., movies, events, weather, gas prices, traffic incident data,etc. It is used for a combination of spatial and temporal-spatialsearches.

The points-of-interest database 660 shown in FIG. 13 storespoint-of-interest search data. It uses stored-procedures for executingcomplex query logic. It supports queries that have both spatial andnon-spatial criteria, and preferably supports customer-provided content(e.g., “custom-poi”). Some services may use a subset of this data viaSQLite.

With respect to the databases 652-660, some data is accessible from anycluster running core services. Some data is read-only. This is generatedby offline processes, such as vendor feeds or quarterly NAVTEQ updates.It can be stored as one copy per cluster or one copy per machine forreliability and performance. On the other hand, some data is write-only.This is transient, replaceable data, and ‘precious’ data that cannot be(easily) regenerated.

FIG. 14 shows an exemplary physical database layout, in accordance withthe principles of the present invention.

The databases include global data, e.g., the User DB 652 and the TrafficDB 656. The databases use Oracle 10 g RAC for fault-tolerance, and EMCstorage (RAID10).

Read-only databases include, e.g., the SearchBuilder DB 658, and the POIDB 660. Read-only databases use multiple instances of Oracle 10 g, eachone a copy of the others. SQLite uses one instance per machine that runsservices using the read-only data.

Write-only databases include, e.g., the Monitoring DB 654. They usePostgreSQL. They store precious data immediately, from the service inwhich it was generated. For example, first time user, billing events,etc. It can be aggregated later via offline processes. For heavy dataloads, write throughput is critical. They reduce disk I/O and apply‘best-effort’ semantics for non-critical data.

FIG. 15 shows a Map Tile Server, in accordance with the principles ofthe present invention.

Dynamic map tile generation functions with no pre-rendered web tiles. Ituses multi-tiered caching. Tiles are served immediately from front-endcache (if implemented). Metatile caching increases reusability of tileswithout having to redraw the map. A Pre-caching tool loads popular areasduring service initialization. A RESTful web-based interface increasesaccessibility.

FIG. 16 shows detailed architecture, in accordance with the principlesof the present invention.

AtlasBook USER INTERFACE (UI) FLOW

FIG. 17 shows a top level user interface flow for the carousel, inaccordance with the principles of the present invention.

FIG. 18 shows exemplary user interface flow for application launch ofthe AtlasBook Navigator, in accordance with the principles of thepresent invention.

FIG. 19 shows exemplary user interface flow for voice recognition forSay Business, in accordance with the principles of the presentinvention.

FIG. 20 shows point of entry states, in accordance with the principlesof the present invention.

FIG. 21 shows point of entry states for non-touch screen embodiments, inaccordance with the principles of the present invention.

FIG. 22 shows exemplary user interface flow for landing zones, inaccordance with the principles of the present invention.

FIG. 23 shows exemplary user interface top level flow for locationselection, in accordance with the principles of the present invention.

FIG. 24 shows exemplary user interface flow for non-touch screenlocation wizard operation, in accordance with the principles of thepresent invention.

FIG. 25 shows exemplary user interface flow for touch screen locationwizard operation, in accordance with the principles of the presentinvention.

FIG. 26 shows exemplary user interface flow for entry and acceptance ofa license key, in accordance with the principles of the presentinvention.

FIG. 27 shows exemplary user interface flow relating to a user's accountinformation, in accordance with the principles of the present invention.

FIG. 28 shows exemplary user interface flow relating to launch ofAtlasBook Navigator from Contacts, in accordance with the principles ofthe present invention.

FIG. 29 shows exemplary user interface flow relating to launch ofAtlasBook Navigator from Calendar, in accordance with the principles ofthe present invention.

FIG. 30 shows exemplary user interface flow relating to synchronizationof Events, in accordance with the principles of the present invention.

FIG. 31 shows exemplary user interface flow relating to please waitscreens, in accordance with the principles of the present invention.

FIG. 32 shows exemplary user interface flow relating to voice navigationfor the feature Say Airport, in accordance with the principles of thepresent invention.

FIG. 33 shows exemplary user interface flow relating to voice navigationfor the feature Say Address—Nuance, in accordance with the principles ofthe present invention.

FIG. 34 shows exemplary user interface flow relating to voice navigationfor the feature Say Address(Vlingo), in accordance with the principlesof the present invention.

FIG. 35 shows exemplary user interface flow relating to launch ofAtlasBook Navigator under a third party's trademark, in accordance withthe principles of the present invention.

FIG. 36 shows exemplary user interface flow relating to launch ofanother embodiment of AtlasBook Navigator, in accordance with theprinciples of the present invention.

FIG. 37 shows exemplary user interface flow relating to a clickableembodiment of the Carousel, in accordance with the principles of thepresent invention.

FIG. 38 shows exemplary user interface flow for first time through (FTT)provisioning of the AtlasBook Navigator, in accordance with theprinciples of the present invention.

In particular, as shown in FIG. 38, PROBES_EULA is shown during FTT. Ina first case scenario, the user accepts launch of AtlasBook Navigator,the decision is remembered and the user is never required to read theEULA (license agreement) again. They can turn Share Traffic on and offat will. There is a small amount of non-EULA text added to thepreferences screen, in a similar manner as for the traffic preferences.

In a second case scenario, the user declines launch of AtlasBookNavigator during FTT. In this scenario the Share Traffic preferences isnot set to FALSE, there is the same small amount of text explaining thefeature, written directly on the preferences screen. If and when thesecond case scenario user changes the preferences to Traffic ON, thePROBES_EULA is re-downloaded and presented with Accept/Decline buttonsjust as per FTT. If they accept, they will never see the EULA again andbecome like a first case scenario user. If on the other hand theydecline, they will see the PROBES_EULA each time they try and turntraffic sharing ON until they eventually accept.

FIG. 39 shows exemplary user interface flow for SPG Storm/Curve2 typedevices, in accordance with the principles of the present invention.

FIG. 40 shows exemplary user interface flow for SPG Calgary/Palm typedevices, in accordance with the principles of the present invention.

FIG. 41 shows exemplary user interface flow for launch of an alternateembodiment of the AtlasBook Navigator, in accordance with the principlesof the present invention.

FIG. 42 shows exemplary user interface flow for first time through (FTT)purchase of a license for use of an AtlasBook Navigator product, inaccordance with the principles of the present invention.

FIG. 43 shows exemplary user interface flow for upgrade of the AtlasBookNavigator product & services from a map view, in accordance with theprinciples of the present invention.

FIG. 44 shows exemplary user interface flow for operation of a locationwizard for selecting location, in accordance with the principles of thepresent invention.

FIG. 45 shows exemplary user interface flow for working through a user'saccount information, in accordance with the principles of the presentinvention.

FIG. 46 shows exemplary user interface flow in a Carousel view of theAtlasBook Navigator; in accordance with the principles of the presentinvention.

The personal wireless navigation system is preferably compatible withthe following operating environments: J2ME, Blackberry Java (native),Windows Mobile 6—Professional (Pocket PC) and Standard (Smartphone)Editions, Brew 2.1.3, Brew 3.1.4, Mac OS X (iPhone), Android, Symbian(UIQ and S60), Linux, and Windows Mobile 7.

FIG. 47 shows a minimum device list for the form factors for AB and thepersonal wireless navigation system, in accordance with the principlesof the present invention.

The personal wireless navigation system is provided as two LBSapplications—AtlasBook (AB) v5 and AtlasBook Navigator (ABN) v5,permitting a user to upgrade to or opt in/opt out from AB v5 to ABN v5.AtlasBook v5 and AtlasBook Navigator v5 are two distinct products thatare launched simultaneously as part of the total LBS eco-system.AtlasBook v5 provides flexibility for partners that continue to havenon-GPS devices, as well as an economical and competitive solution toall mobile LBS applications.

The AtlasBook v5 (AB v5) personal wireless navigation system is marketedas a low price or even as a free application that is either preloaded ordownloaded from a suitable server supporting the TeleCommunicationSystems/NIM website or other web shop. AB v5 provides local searchincluding search for POI, weather, movies, events, traffic; plus mappingand static directions with tracking, but without “guidance”.

The AtlasBook Navigator v5 (ABN v5) personal wireless navigation systemprovides all the capabilities of AB v5 plus real time turn-by-turn‘Navigation’, including ‘guidance’ (recalculations, maneuverannouncements unrelated to turns), Only ABN v5 provides traffic enablednavigation and offers the option for detour.

For a price AB v5 users may upgrade from AB v5 to ABN v5, for a singleuse, a day, for a month, per month, per year, etc.

“Initial Activation” refers to the first time AB is downloaded oractivated (if preloaded). This refers to both scenarios where a brandedversion of AB is free or available for a fee.

A “purchase” is defined as activating idle functions of AB to providefull ABN functionality, without necessarily having to download anyresource files or application files.

An “upgrade” is defined as downloading an additional application orfiles to the standard ABN that either provides users with additionalfunctions or content.

In selected areas of the personal wireless navigation system, AB v5notifies users about the benefits of purchasing the personal wirelessnavigation system and invites them to choose from a list of purchaseoptions, such as: Purchase ABN for this one time; Purchase the personalwireless navigation system for a day; Purchase the personal wirelessnavigation system on a monthly subscription basis; Purchase the personalwireless navigation system for life of the device; or Purchase ABN for a‘custom defined period’ (typically only used for sales demo and trialopportunities.)

AB v5 preferably includes all the application files for the full versionof the personal wireless navigation system. When users purchasenavigation and other functions of ABN v5, those functions are unlockedand any necessary resource files are downloaded from theTeleCommunication Systems/NIM server as part of upgrading to the ABN v5personal wireless navigation system. This allows the purchase process tobe quicker than in the scenario where all the application files andresource files need to be downloaded.

FIG. 48 illustrates one avenue for purchasing the personal wirelessnavigation system, in accordance with the principles of the presentinvention.

If a user chooses to terminate using navigation, those additionalfunctionalities are once again locked, and users may continue using ABv5.

A user may upgrade their personal wireless navigation system to includepremium functions and content. For instance, the personal wirelessnavigation system is designed such that either TeleCommunicationSystems/NIM or its partners can offer certain functions and content aspremium functions and content for an additional fee, in one or morecountries, where the data is available. Premium functions and contentinclude (but are not limited to), for instance, traffic information usedfor navigation and mapping, 2D and 3D sliding maps, movies & events,weather, other?

To support the above, certain functionalities are configurable.

For instance, billing flexibility is provided. Today, “carrier” billingoptions (example BREW) are supported. In these models, users pay thecarrier, either directly or indirectly, and billing issues are handledeither by the carrier or a third party. The personal wireless navigationsystem includes support for several new billing requirements, includingsupport for the sale of products that may be sold in any of thefollowing scenarios: monthly recurring, daily (24 hour), or“session”—used for one navigation. In each of these scenarios, usershave various options, including: pay by credit card or other billingservice, add purchase to an existing mobile account, or purchase througha premium SMS message (in some situations). Billing also preferablysupports demo capabilities, test accounts, and other no charge options.

The AB v5 personal wireless navigation system preferably includesoptions for potential users to perform the following:

-   -   Discover the application on a web site(s).    -   Use the site to determine whether the application is available        to work on a specific device/network combination.    -   Link to a service to set up payment options.    -   Receive confirmation that the payment is accepted (email or SMS)        along with a means to access an appropriate download of the        application (suitable for the identified device).    -   Download the application automatically.    -   Easily access and start the downloaded application and link a        proof of payment.

FIG. 49 illustrates an exemplary flow chart for a billing process, inaccordance with the principles of the present invention.

Upgradable Location Based Services (LBS) Website

The personal wireless navigation system LBS website companion preferablyincludes the following new functionalities and enhancements to supportand compliment the personal wireless navigation system mobileapplication:

In general, the AtlasBook personal wireless navigation system brandedwebsite is open to the public for:

1. POI mapping and search including gas prices.2. Movies and events search.3. View traffic on maps including incident data.4. View and print static directions.5. Place sharing to email addresses and any mobile phone (received astext).

For users who do a have an AtlasBook Navigator personal wirelessnavigation system on their wireless phone, once they log in theypreferably can do all the above plus:

6. Send place messages to all users with the personal wirelessnavigation system running on their wireless phone.7. Synchronize recent searches and favorites between mobile and website.8. Add their own POI categories.9. Map a friend's response(s) to a GeoPoke(s) on a website.

Store Front for Purchasing and Downloading the Personal WirelessNavigation System—Website

The personal wireless navigation system website provides a pagededicated to purchasing and downloading the personal wireless navigationsystem (e.g., AB v5).

During the purchase process for the personal wireless navigation system,log-in accounts are preferably created for the users.

The personal wireless navigation system users have the option toindividually sign on to the website using an account that was createdfor them during the purchase and download of the personal wirelessnavigation system. Certain capabilities such as mapping and POI searchare available without purchase of ABN. Other capabilities such assynchronization are available to the valid ABN users only after theylog-in.

The personal wireless navigation system preferably includes automaticspeech recognition (ASR). The ASR solution includes the ability to speakaddresses or ask for a POI, in a single utterance. The ASR capabilityuses vlingo as the primary provider. A generic solution that can be usedby either vlingo, Nuance, etc. is more desirable, but the priority isfor an ASR solution that supports vlingo.

ASR (automatic speech recognition) reduces the frequency that the userneeds to touch the device, which is extremely useful to drivers,Speaking addresses or long words is easier than typing them on ahandheld device. In operation, the user speaks the address, businessname or category, and the spoken words are converted to text before thepersonal wireless navigation system conducts the search. If there ismore than one match, preferably all possible matches are displayed sothat the user can disambiguate.

The ASR powered by vlingo includes a very flexible “single utterance”type solution that enables a subscriber to speak an utterance on the topmenu and either navigate to an address or select a POI from a list(category or name).

The ASR replaces the current top “local business” only ASR collectionbox on the top screen with a more generic capability that enables anyaddress, airport name, or POI name or category to be spoken andappropriately decoded. It also creates a “disambiguation” option toenable the user to define the type of input, if the result of speechrecognition could be more than one thing (most likely either an addressor a location). An example of the earlier concept for disambiguation isattached, though a command option is possible.

FIGS. 50A and 50B show an exemplary sequence when a user speaks acomplete or partial address, the personal wireless navigation systemprocesses the single utterance as a destination, and displays theprocessed text in the appropriate address fields, in accordance with theprinciples of the present invention.

As shown in FIGS. 50A-50B, the user can type or speak the values, if anyof them were processed incorrectly. The user then may press NAV or go toan options menu to perform another function.

FIG. 51 shows when the user speaks a POI category or name, the personalwireless navigation system processes the spoken word and displays theprocessed text in a ‘What’ field. The user can type or speak the term,if it was processed incorrectly, and then may press FIND to get anoptions menu to perform another function.

When the user speaks a POI category or name at an address or airport,the personal wireless navigation system first displays the spoken POIcategory or name, and then processes the spoken address or airport, andthen displays the processed text in the ‘What’ field. The user may typeor speak the term, if it was processed incorrectly. The user can thenpress FIND to get an options menu to perform another function.

The personal wireless navigation system also allows users to speak amovie title, event type such as ‘Concerts’ or event name such as‘Pageants of the Masters’, and the personal wireless navigation systemprocesses the spoken words similar to how it would process POIcategories or names.

A merchant paid search functionality provides the ability to cover somedata costs, and helps wireless operators and partners to potentiallylower the subscription prices as price erosion catches up with mobileGPS Navigation. There are also benefits to the end users, as they seemore relevant information about the POI and businesses that they aresearching for.

In a given embodiment, it is recognized that some subscribers who searchfor a certain type POI, e.g., hotels, may be enrolled in several hotelrewards program and would find it useful to see only those brands.Likewise, some POIs and businesses would pay to present certainmarketing or other retail information to a user requesting the POS. Inone example, user generated reviews and/or ratings about the POIs may bepresented to the user.

The personal wireless navigation system may also show coupon informationoffered by the merchants.

FIGS. 52A and 52B show an exemplary “please wait” display area, in thegiven embodiment a gray area in the screen, recognized by the inventorsherein to be a preferred area where an advertisement or other paid-forinformation may be placed within the screen.

As an example, the dimensions associated with the “please wait” grayarea shown above in a PQVGA display are 176 px wide by 40 px high. Inthis given example, the user launches their application on theirwireless device and selects execution of the navigation program. Theuser then selects a location they would like to navigate to. As soon asthey select Nav, an integrated “Please Wait” screen is displayed with novisible delay. Since this is a navigation “Please Wait,” the clientpreferably integrates a run of a paid-for network banner into the areaotherwise normally comprising a “Please Wait” information screen.

When local search is performed using one of eight predetermined premiumcategories (traffic, restaurant, hotels, ATM, gas, weather, movies,events), the user launches the personal wireless navigation applicationand selects operation of the navigation application. The user thenselects a location that they would like to navigate to. As soon as theyselect “Nav,” the integrated “Please wait” screen is displayed withoutsignificant or visible delay. Because this is a specific category of the“Please wait” screen, the client may integrate paid-for information in asuitable banner appropriate to the keyword (category) into the area ofthe display previously displaying “Please wait.”.

As an example, when Local Search is performed using one of the othercategories, the user launches the personal wireless navigationapplication and selects navigation. The user then selects a locationthat they would like to navigate to. As soon as they select Nav, theintegrated “Please Wait” screen is displayed with no visible delay.Since this is a non-specified category “Please Wait,” the clientintegrates a run of the network into the “Please Wait” screen.

In a given embodiment, premium placement advertising is displayed orotherwise appears only when a local search is performed, whether for aspecific category or for all categories around a specific geographicallocation. The TeleCommunication Systems/NIM server preferably passes asmuch information as possible to an Idearc server to get the mostrelevant advertisement response for the user's search criteria includinglocation information, plus the category and/or sub category and/or anykey words.

FIG. 53 shows an exemplary “Please Wait” screen with premium placementadvertising.

In a preferred embodiment, the user has the ability to click on thedisplay to see additional information as well as initiate a call to thelocation by pressing the call key on the handset.

In an example showing a premium placement local search use case, whenLocal Search is performed specifying a category and sub-category, thefollowing occurs:

The user launches application and selects local search. Then the userselects a category (e.g., eating and drinking). The user then specifiesa sub-category (e.g., Italian). Both eating and drinking as well asItalian are sent to the Idearc server along with the location. Thus,while Search Builder performs the POI results, all of this informationis sent to Ideards server and relevant or desired advertising resultsare obtained back by the personal wireless navigation system.

Continuing on, the geo information is provided back in the ad resultsand this information is used to calculate the Premium Placement ad'sdistance from the user. The search results are returned to the clientand the first line item displayed is, e.g., “0.8 mi Olive Garden,<address>, <etc.>”.

Other search results display in the standard distance order includingItalian restaurants that are closer than the Olive Garden in thisexample. While distance is included in the banner, it is preferably notused to determine the placement within the display. In the preferredembodiment, the ad always appears in the same location, e.g., at thetop.

Preferably the personal wireless navigation system website also providespaid merchant information including banner advertisement and premiumplacements, similar to how it is deployed on the mobile application.

The messaging capability of the personal wireless navigation systemallows users to poke, referred to herein as “GeoPoke”, their friends andrequest their location. Users are able to request friends' locations bycomposing and sending a place message that has the default greeting,e.g., “Where are you?” The recipient or recipients can respond withtheir GPS location. In this way, the messaging capability enhancessocial networking capabilities of the personal wireless navigationsystem.

FIGS. 54A and 54B show when a geo poke or response to a geo-poke isreceived, it preferably includes brief information or a flag identifyingthe brand of the personal wireless navigation system to the receiver,such that the receiver knows that they are getting poked by someone whohas a branded version of the personal wireless navigation system ontheir phone.

The same is supported via the website. In particular, the personalwireless navigation system users who sign in and had GeoPoked theirfriends from either the website or mobile application are able to getthe response on the website, such that the location of the response(friend's location) is displayed on the map, as well as any textresponses that the friend appended to the GeoPoke response.

FIG. 55 shows that when a geo poke or response to a geo-poke isreceived, it includes brief information or a flag identifying the brandof the personal wireless navigation system to the receiver; such thatthe receiver knows that they are getting poked by someone who has abranded version of the personal wireless navigation system on theirphone.

Conventional place messaging and GeoPoking is only possible within thesame brand of personal wireless navigation system, e.g., withinAtlasBook v4. In accordance with the invention, place messaging in thepersonal wireless navigation system is enabled cross brand/crossplatform, cross carrier. This is because competitive mobile LBSapplications including Telmap and telenav enable users on differentcarriers to share locations. In the personal wireless navigation system,place messaging capability is extended to enable cross branded productsto be able to send and receive place messages cross platforms (WM, Brew,J2ME, BB-J2ME, etc.,), cross carriers.

FIG. 55 shows an example where a AAA Mobile user on an AT&T networkreceives a place message from a Your Navigator user on the US Cellularnetwork, in accordance with the principles of the present invention.

Traffic Probes

The personal wireless navigation system uploads the speed of its usersto TeleCommunication System/NIM servers, and the information isprocessed and made available as real time traffic data. The personalwireless navigation system samples and logs the speed of the user basedon traffic partner requirements and uploads them to optimize the usageof network resources. In this way near-real-time GPS traffic probe datamay be achieved.

Users of the personal wireless navigation system may be prompted withthe option to provide their speed information and other informationwhile they drive to enhance traffic based navigation. This may beaccomplished via pop up as a new EULA extension. This option may beaccepted or modified by each carrier as required to meet user privacyrequirements.

For “approved” users, during operation, the system collects informationon actual travel speeds for road segments. These speeds are stored in afile for transmission to TeleCommunication Systems/NIM servers at pointsduring product operation. The transmission of this information Ispreferably automatic, requiring no user intervention. At a minimum theinformation preferably comprises: LAT/LON, plus direction of travel andspeed, and the date/time for each collection. Preferably, to ensureprivacy of users, no information that could identify the user istransmitted in this regard.

The number of samples is determined based on traffic partnerrequirements. The primary goal is not to impact perceived systemperformance for the user. An ancillary goal is not to burden the networkwith extraneous data transmission.

Particular NAVTEQ Requirements are met based on “hard” probe data, withfixed devices in commercial vehicles. Particular NAVTEQ informationcollected by the Traffic probe includes:

-   -   The handle remains anonymous.    -   Latitude (5 decimal place precision).    -   Longitude (5 decimal place precision).    -   Speed (e.g., in kilometers per hour).    -   Heading (in degrees, 0 degrees=North).    -   Timestamp of observation (year, month, date, hour, minute,        second, (e.g., in GMT)).    -   Timing.    -   Frequency of collection. In the preferred embodiment, each data        point is collected once every 15 seconds and stored on the        device until transmission back to a central server.    -   Transmission periodicity. In the preferred embodiment, the        collected data is transmitted back to a central server on a 15        minute interval (or shorter interval to the extent the carrier        infrastructure can support a higher frequency of transmission).        At each 15 minute interval (or shorter interval to the extent        the infrastructure can support a higher frequency of        transmission), the saved data points are placed into a single        packet and transmitted back to a central server.

A traffic probe web service allows Traffic.com to collect and manageanonymous probe related data. Preferably a single anonymous handle, orreference string, is associated with each point within a single packet,though it need not be the same from one packet to the next. Anonymousreference strings are unique for every packet. There is thus nopersistent link between data points and the device from which theyoriginate, An exemplary method is sendProbeData, which is anasynchronous method which accepts multiple, anonymous probe datareadings for Traffic.com's consumption.

The Authentication Web Service provides access to user and web serviceclient login using a method called authenticateWebServiceClient.authenticateWebServiceClient authenticates the web service client andreturns a client context.

The schema represents the structure of the data in the traffic probe webservices. The scheme WebServiceClientContext.xsd is used for web serviceclient authentication, and enables Traffic.com to secure access to webservices based on the client making the calls.

Probe.xsd represents the probe related data types.

ProbeData represents anonymous probe device, location, heading and speeddata

GlobalPosition represents the global positioning data.

GeoLocation represents latitude and longitude.

An application tray is established on the wireless device toconveniently permit selection of various location based programs. In thepresent invention the branding is called “NAVBuilder version 5” or“NAVBuilder v5.” NAVBuilder v5 version is for the same platforms, fromwhich device specific extensions can be derived, for 3^(rd) partyapplication development targeting multiple carriers. Additionally,App2App and Web2App APIs are supported.

Other device applications support LBS functionality, and thus the samenavigation application is leveraged whether integrated or invoked by theapplication. App2App and Web2App APIs enable 3^(rd) party developers toinvoke AtlasBook Navigator v5 from other device applications, WAPapplication, or Web application.

NAVBuilder for v5 is preferably delivered as an SDK, supporting multipleplatforms and carriers without modification to the core architecture. Ifthere are limitations to delivering a single SDK, it is necessary tosupport SDKs for the following platforms: C-based (Windows Mobile,iPhone, BREW, Linux, Symbian) and Java (Blackberry, J2ME).

The NAVBuilder APIs support allowing the user to create a user interface(UI) that conforms to the graphical user interface (GUI) of the parentapplication, as well as, offer 3^(rd) parties the capability to use theexisting graphical user interface (GUI).

As an example, one 3^(rd) party has an application that does not usetext boxes, as shown in the example below. NAVBuilder for v5 allows thedeveloper to create a GUI that has a similar look and feel to the parentapplication. The NavBuilder, App2App, and Web2App is delivered as fourcomponents: libraries supported by APIs in core platform, internalspecifications, 3^(rd) party documentation, and sample code.

NAVBuilder preferably supports multiple APIs, such as: Navigation; PlanTrip; Localization Preferences; Address Lookup; and Preferences.

The exemplary Navigation API supports all features of AtlasBookNavigator 5 including: Real-time, turn-by-turn driving directions;Support for resuming an interrupted navigation session; Automaticre-routing; GPS-based navigation; Voice prompts; display of trafficinformation; and detour options including trip update and trip summaryusing traffic data.

The Plan Trip API supports all features of AtlasBook Navigator 5including: user input to select start and destination locations, tripsettings, and how they use traffic; and user capability to reverse trip.

The Local Search API supports all features of AtlasBook Navigator 5 tosearch for POIs by name or by category around a specific point, along aroute, or in a certain direction.

The Maps API supports all features of AtlasBook Navigator 5 fordownloading and rendering, both 2D and 3D sliding vector maps, 3DPerspective View, Sliding vector maps, and support for Traffic alertsoverlay.

The Localization Preferences API supports user options to selectlanguages and maps, as specified in country support for AtlasBookNavigator 5.

The Address Lookup API supports all features of AtlasBook Navigator 5for finding the address or intersection of given coordinates or findingthe coordinates of a given address or intersection. The followinginformation is supported: Street name and number in any sequence, city,state, zip code, and country.

The Preferences API supports all features of AtlasBook Navigator 5 forenabling user preferences for Navigation options, Map options, Language,Trip Settings, Country selection.

App2App supports all features supported for the conventional version 4plus new features supported in AtlasBook V5 Navigator includingInternationalization and new route types (e.g., pedestrian).

WebApp supports all features supported for V4 plus new featuressupported in AtlasBook V5 Navigator including Internationalization.

When users run the navigation program, they always have the ability tobenefit from the program's primary purpose, providing route guidance,the product's primary purpose. Thus, through NAVBuilder, other functionsrun without suspension of navigation on the mobile device providing thepersonal wireless navigation system. For instance, if a navigationsession is running, and if a user views a traffic summary including anytraffic incidents, map of route, etc., the navigation session continuesto run.

It is preferable, though not absolutely required, to perform somefunctions such as POI search and sharing without suspending navigation.For instance, if a user decides to search for POI, or view the trafficsummary, maneuver announcements continue to play, and once the userreturns to any of the three navigation view modes, the information onthe screen is maintained up to date.

As another example, if a user is navigating and then decides to do anyof the actions (such as viewing traffic summary; viewing an incidentdetail; viewing a map of the route, map of incident, or map of a stepalong the route; conducting a local search; or composing and sending aplace message), the navigation continues to run, to play maneuverannouncements, recalculate an announcement if necessary, and/or adjustthe trip parameters in the background until the user returns to thenavigation screen.

The personal wireless navigation system preferably displays animmediately required section of the route quickly by utilizing ‘datastreaming’ to illustrate the first few segments of the route. Forexample, if the navigation system starts up while the personal wirelessnavigation system is “on-route,” the first maneuver map and announcementis preferably displayed quickly, e.g., within 3 seconds after the userpresses NAV. If the personal wireless navigation system starts up whilethe mobile device is “off-route,” the first maneuver map andannouncement is also preferably displayed quickly, e.g., within 3seconds after the user presses NAV.

Thereafter, the personal wireless navigation system continues todownload the remaining portion of the route in the background—regardlessof whether it is a short route or long route. If it's a longer route, ittakes a while for the first announcement to play as the mobileapplication waits until the entire route is downloaded, before the firstmaneuver announcement is played. But the personal wireless navigationsystem displays the start of the route quicker, e.g. within a maximum of3 to 5 seconds, depending on an on-route versus off-route condition.

The personal wireless navigation system uses similar techniques tostreaming video download, by displaying and playing the first fewmaneuver announcements and displaying the first few maneuvers while theapplication downloads the information necessary to render the rest ofthe route which includes segments that users will not encounter for sometime.

If a user decides to look ahead while the personal wireless navigationsystem displays the first few segments of the route and is in process ofdownloading the remaining segments, the look-ahead screen informs usersthat the information is being retrieved.

Similarly, if a user decides to view a trip summary or a trafficsummary, the personal wireless navigation system displays a screenindicating that the information is being retrieved.

The personal wireless navigation system uses better position estimationbetween fixes and in poor coverage areas (tunnels & building canyons) indeterministic areas, with simple cases. In this way the user experienceis enhanced in poor coverage areas so that the personal wirelessnavigation system becomes more competitive with on-board solutions.

In doing this, the personal wireless navigation system uses currentspeed to estimate upcoming position and cache the parameters in theevent that the driver enters areas with poor coverage. The personalwireless navigation system also utilizes secondary sensors, ifavailable.

For instance, if a driver enters a tunnel, the personal wirelessnavigation system is unable to get a GPS fix. Nevertheless, based onsampled speed values, the personal wireless navigation system estimatesthe driver's position, and preferably any maneuver announcement thatneeds to be played, including announcement of any impending exit insidethe tunnel or immediately after the tunnel, as the device may not haveample time to get a fix and update the information on the screen in timefor the driver to prepare for the maneuver.

Preferably the distance to the maneuver is counted down (e.g., with abackground in color yellow instead of color teal).

For an off-route start up case, the personal wireless navigation systemprovides enhanced navigation by guiding the user without recalculation,in the event that the user takes a different exit or driveway to gettowards the main route, while continuing to show the user's progresstowards the start of the suggested route.

Users in an off-route start up case may not always take the suggesteddriveway or exit to get to the main road. To reduce the necessary numberof recalculations, the personal wireless navigation system has moreinformation about the start up location and guides the user toward thestart of the route. The inventive personal wireless navigation systemuses maps to guide the user toward the start of the route without theneed to recalculate a new route. Thus, e.g., if a user exits a plazafrom a different road that that which was expected, the personalwireless navigation system does not recalculate, but instead guides theuser toward the suggested route.

With the underlying assumption that 3D-Perspective view is the defaultnavigation view mode, for an off-route start up case, the personalwireless navigation system displays 3D perspective view of the user'sposition oriented such that the start of the route is located at the topof the screen. As the user (which is represented by an avatar on thedisplay) moves toward the start of the route, and eventually gets on theroute, the 3D perspective maps is oriented and slides accordingly. Thescreen also displays all residual information, i.e., total travel time,total distance, traffic gauge, as well as distance to the start of theroute, compass heading, GPS availability, and the upcoming maneuver type(left turn versus right turn).

If the ‘2D-Top View’ is set as the navigation view mode, then theoff-route start up case is also displayed in ‘2D-Top View’ mode. If“Dashboard” is the navigation view mode, then the start up case will bea 2D map, and as soon as the user gets to the start of the route, thescreen switches to dashboard view mode.

The vector maps during navigation displays the point of interest (POI)icons of the most relevant POIs along the route on a sliding navigationmap.

For the 3D and 2D navigation view modes, the personal wirelessnavigation system downloads the POI information and displays theirrespective icons for the most relevant POIs along the route, e.g., food,gas, lodging, and rest areas. Each time the personal wireless navigationsystem mobile application downloads new vector information forrendering, it downloads the POI details for these categories as well.

FIG. 56 shows an exemplary touch screen device where a user can click onan icon, and details relating to the clicked-on POI are displayed, inaccordance with the principles of the present invention.

The following POI categories are displayed on 3D or 2D modes for carnavigation: Eating & drinking; gas stations, lodging, public parking,and rest stops. In other modes, e.g., in Pedestrian mode, the displayedPOI categories are different, e.g., restaurants; coffee shops; bars;public restrooms, and ATM's.

The preferred POI for display may be changed. In particular, a settingmay be added under ‘Preferences’ to either allow users their desired (5)POI categories, or allow users to select from a predefined theme ofcategories, each encompassing the most relevant POI category for therespective theme. As examples, a “Business Travel” POI categoryincludes: car rental return; train/shuttle/bus stops; gas stations;copy/mailing centers; and hotels. a “Tourist—Pedestrian” POI categoryincludes: shopping centers; coffee shops; train/bus stops; restaurants &bars; museums, galleries and historical sites; public restrooms; andATMs. A “Road Travel” category includes: gas stations; rest areas; autorepair; restaurants; historical sites, museums and vista points; andhotels & motels. A “Weekend On The Town” category includes: weekendspecials—stores with discounts, blow out sale (merchant paid search);eating & drinking (specializing in new openings); street festivals &fairs; public parking; and ATMs. A “Commuter” category includes: gasstations; coffee shops; restaurants; fast food; and ATMs. (Note thepossibility to overlap POIs within multiple categories.)

A user is able to remove and thus disable any or all POI categories fromshowing on the navigation maps or screens. The capability to displayspecific POI categories is also available via Follow Me Map, and Map ofRoute, and Map of Step.

The personal wireless navigation system preferably supports time basedturn restrictions for all road types including HOV lanes. For instance,whenever the personal wireless navigation system calculates a route, ituses the time tables attached to each segment with turn restriction, andreturns a route that avoids all segments that the user will not be ableto traverse, given the expected travel time window.

Time-based high occupancy vehicle (HOV) lane support is also preferablyprovided. For instance, if a user has explicitly chosen to avoid HOVlanes, the personal wireless navigation system will honor this userpreference setting when the HOV rules are enforced. Otherwise they areignored and such lanes may be part of the route if it yields the optimalroute given the remaining rules and/or restrictions.

Time-based turn restriction is supported by the personal wirelessnavigation system in consideration of all route segments that qualifyduring the expected time of travel therethrough.

The personal wireless navigation system provides real time notificationfor other road attributes as drivers approach, e.g., toll plazas, areaswhere cameras are installed, tunnels, and ferry docks.

The attribute icon displays the speed limit for the segment, so that thedriver can compare it to the actual speed on the odometer at a glance.

The personal wireless navigation system displays an icon representingeach attribute type on each navigation or look-ahead screen, e.g., speedlimit, camera zone, tunnels, or ferry docks. Preferably the personalwireless navigation system provides distinct audible and/or visualnotification for each such attribute type.

For instance, the personal wireless navigation system may also beconfigured to notify the driver if they are sensed to be going fasterthan the posted speed limit. Alternatively a compliance buffer of, e.g.,specified as a percentage such as 14%, or as a mph such as 9 miles perhour, may be configured so that the driver is not notified unlessexceeding the posted speed limit plus a given compliance buffer for thatspeed.

Drivers and their passengers may require extra time to prepare as theyapproach areas with attributes requiring potential action by the driver,for instance camera zones in which the driver should become moreattentive to their surroundings. In such a case, the personal wirelessnavigation system provides notification of a given camera zone. Forinstance, the personal wireless navigation system notifies drivers witha suitable announcement such as “Warning! Traffic camera ahead!” inadvance, as they approach a traffic camera zone (or a stop light camera,or speed camera, etc.): The rules for timing of this announcement aresimilar to the rules for announcing an upcoming maneuver.

The notification also sets an expectation for the driver that theapplication may behave differently based on the attribute that they areabout to encounter, e.g., an impending tunnel requiring potential actionby the driver. The tming of a maneuver announcement relating to theimpending tunnel may be different in anticipation of areas with poorcoverage.

As another example, the personal wireless navigation system may notify adriver with a suitable audio announcement such as “Approaching Tunnel in<X> miles (yards or feet)!” in advance, as they approach the relevanttunnel. Rules for timing of this announcement are similar to the rulesfor announcing an upcoming maneuver. These rules are augmented byenhancement requirements to navigation in areas with poor coverage.

In a similar vein, if there is toll plaza at a tunnel entrance, then thepersonal wireless navigation system uses a toll plaza notificationannouncement followed by the tunnel notification announcement, and theattribute icon toggles back and forth in intervals of, e.g., 3 secondsor more.

These features increase the usefulness of the personal wirelessnavigation system, particularly as it offers some basic features foundin conventional portable navigation devices (PNDs) and in-car navigationsystems, but adds significantly thereto. Some early features of thepersonal wireless navigation system were deployed in earlier versions inNordisk Navigator in Europe.

For 3D and 2D, an attribute icon is displayed at the top center portionof the screen so that it does not interfere with the rules fordisplaying the other indicators—compass, GPS availability, and trafficalerts.

Finally, the personal wireless navigation system provides a configurablesetting to disable/enable any or all of the alert types.

Ferry docks may require certain functions of the application such as TBTnavigation to not be available while the user is on the ferry. Thepersonal wireless navigation system includes a ferry dock notificationthat notifies a driver with a suitable announcement such as thefollowing announcement in advance, as they approach a given ferry dock:“Approaching Ferry Dock, in <X> miles (yards or feet)! The rules for thetiming of this announcement are similar to the rules for announcing anupcoming maneuver.

The personal wireless navigation system provides users the option toview follow me maps in 3D perspective or 2D top view, similar to a userexperience found in conventional portable navigation devices and in-carnavigation systems. The options menu for the Follow me map includes theoption for changing view mode from 3D (default) to 2D. The defaultsetting for the follow me map may be 3D for some branded versions of thepersonal wireless navigation system, in order to be consistent withexpected user experience, and provider requirements. On the other hand,the default setting for the Follow me map may be 2D for other brandedversions of the personal wireless navigation system, particularly ifusers explicitly select ‘Pedestrian’ mode.

The personal wireless navigation system includes an enhanced pedestriannavigation function which provides a top view mode, similar to ‘FollowMe Map’ behavior, higher zoom levels, and bread crumbs, just to name afew examples. To provide good pedestrian navigation, the pedestriannavigation of the personal wireless navigation system meets therequirements of a typical pedestrian, which is different from a driver.Therefore, the pedestrian navigation behavior and use cases aresignificantly different from those for automobile navigation.

Conventional portable and in-car navigation products provide a trafficalert announcement just once for any given incident or congestion. Thepersonal wireless navigation system uses a rule to re-announce a pasttraffic alert announcement at least one more time. This re-announcementrule is based on several conditions, including: the distance traveledfrom the point when the first announcement was played; the distance tothe location of traffic alert; the time that has elapsed since the firstannouncement was played; and/or a logical combination of above.

Conventional portable and in-car navigation products use the sameannouncement for alerts regardless of which side of the road theincident or congestion is at. The personal wireless navigation systemuses a distinct, unique announcement type for a reported incident orcongestion that is on the opposite side or direction of the road on theusers' route. Example unique announcement types for an alert relating tothe opposite direction of the road includes:

“Traffic congestion ahead in X miles on eastbound <road name>”, usedwhen the user is approaching congestion from a westbound direction.

“Traffic incident ahead in X miles on westbound <road name>”, used whenthe user is approaching congestion from an eastbound direction.

“Traffic congestion ahead for the next X miles on northbound <roadname>”, used when the user is approaching congestion from a southbounddirection, etc.

Wherever necessary, the personal wireless navigation system uses the 3Dengines of the hardware such as OpenGL ES 1.0 to support 3D graphicswith improved performance—if and only if the architecture for thepersonal wireless navigation system mobile application can benefit fromthem.

Enhanced Trip Summary Screen

On selected devices with larger screens, an enhanced trip summary screenis used to provide trip summary information illustrated such that itlooks more like an automobile dashboard rather than a page full of text.

FIG. 57 shows an exemplary enhanced trip summary screen, in accordancewith the principles of the present invention.

In the personal wireless navigation system, when a user pans the map,the application responds quickly by panning the map instantly, andgetting or drawing the new areas of the map. In conventional portable orin-car navigation systems, the application waits before the completedisplay area is rendered or downloaded, before it shows the result tothe user. Also, when the user pans, the screen does not refreshinstantly and waits until the new map is loaded. The present inventorshave realized that this is not an optimum user experience as people ingeneral expect immediate response to panning.

The personal wireless navigation system in accordance with theprinciples of the present invention provides immediate response on themap. As soon as the user input requests moving the map, the map pans inthe respective direction (pressing a button, tapping on screen, ordragging on screen). Thereafter, as shown in FIG. 58, the personalwireless navigation system displays new map information, as it becomesavailable.

The personal wireless navigation system leverages the native controls ofthe device platform, and integrates with native applications andservices, including Windows Mobile platforms. Supported native featuresinclude: Menu, Cut, copy and paste, Combo boxes with pull down menus,Buttons, Messaging APIs, List view, Scroll bar enable/disable, Monthcalendar, Progress/Status Bar, Tool Bar Controls, Contacts API, andCalendar API. This applies as well to UI enhancements including the useof combo boxes with pull down menus, buttons, list view, scroll bar,tool bar controls.

The personal wireless navigation system implements scalable graphics.For instance, icon size, fonts and text spacing is designed forscalability to reduce porting time. The Icon size, fonts and textspacing is determined based on the design guidelines of each device ordefined as a percentage of the screen size and dimensions used forspacing.

The personal wireless navigation system preferably meets requirements ofthe Windows Hopper test. The personal wireless navigation systemimplemented in a Windows Mobile environment meets requirements ofMicrosoft Logo Certification.

The personal wireless navigation system handles selection and/orswitching between portrait and landscape display modes for all targetplatforms, taking into consideration accelerometer values and/or otherhardware settings. Some mobile devices require the application tofunction only in portrait or landscape mode. All features and functionsof the personal wireless navigation system application operateseamlessly in both orientations.

Landscape only mode orientation supports buttons or keys on the leftedge or right edge. The default in the preferred embodiment supportsbuttons or keys on the right edge.

When changing orientation in a map screen, the displayed map redrawswithout sending a request to the server.

All settings and configuration information resides within Preferences.

FIG. 59 shows a table identifying where in the application users canchange specific options, and whether the change will be permanent (i.e.,V=Sticky) or temporary (X=non-sticky).

User selection controls have a similar look and feel regardless of theplatform. The user selection controls provide a good user experiencewhether on touch screen or non-touch devices. For non-touch screendevices, user input controls are accomplished through use of atrackball, 0-Pad, or rocker and LSK and RSK.

User selection controls are easily identifiable, meaning that the userimplicitly knows what the function of the control. For example, ashortcut key identified as Map indicates to the user that uponselection, the application downloads a map of the selected item.

For touch screen devices, there is preferably enough spacing betweencontrols to prevent users from accidentally selecting unintended items.

Lines is used in lists (contact list, call list, etc) to separate rowsif list items contain more than one line. For example, category listsand airport lists do not have line separators. Rather, results screenscontaining the name on one line and details on a second line has lineseparators.

The graphics for a footer toolbar/shortcut keys/commands in the personalwireless navigation system are preferably similar to the toolbar footerused throughout the device. It is preferred that numbering of menu listsand options lists be omitted in the personal wireless navigation systemfor touch screen devices and smartphone devices. Instead, either a smallicon representing the function replaces what would otherwise benumbering, or no bulleting is used at all.

The width of each row or field (text entry field and drill own field) isthe same as the pixel width implemented by the OEM device manufacturerin given OEM screens.

For personal wireless navigation system devices with touch screensupport, the personal wireless navigation system utilizes a touchinterface throughout the application for selecting functions, executingcommands and

The personal wireless navigation system supports larger fingertiptargets for user interface controls. The layout of the application ismodified to accommodate larger icons and list text to prevent accidentalactivation of the wrong control. The application has greater spacingbetween menu and list items. This spacing is typically defined by theOEM, carrier, or as a percentage of the display area of the device.Preferably there are no highlighted states when the application launchesits home page.

The personal wireless navigation system uses single gestures such asswipe, drag, click, flick as appropriate to provide functions such asscrolling up and down and panning left and right through the entire liston the screen.

Gestures are specific movements performed by users to get specificresults. Gestures are used to mimic actions typically used with a mouseor keyboard. Gestures can be used to navigate through the application,change screens, drill down to detailed information, zoom, panning, etc.The personal wireless navigation system supports the native gestures ofthe platform. Supported gestures include: touch/tap; touch and hold; andtouch and drag.

Touch/Tap—

Touch or tap requires the user to briefly contact the screen in onelocation. A touch/tap selects an item or invokes an action. It is alsopreferably used to position the cursor for text entry. Touch sequence:DOWN, UP for 250 ms-500 ms. The screen types and the action associatedwith a Touch/Tap include: main menu icons; second layer list or icons;search results; and shortcut keys.

Main menu icons perform a drill down action to the next layer. Secondlayer list or icons perform a drill down action to the next layer.Search Results highlights the item, and shortcut keys invoke the action,i.e. navigates, maps, displays local search options, displays placemessage options, etc.

If the user touches or taps an inactive area of the display, there is noaction.

Touch and Hold—

A touch and hold is a touch that lasts more than, e.g., 500 ms. Thescreen types and the action associated with a touch and hold includes:main menu icons; second layer list or icons; search results; andshortcut keys.

Touch and Drag—

The user touches, holds, and moves their finger without losing contactwith the screen. The item touched moves in the direction of the motionof the finger. A touch and drag gesture is used to scroll a list ofitems either up or down. The screen will move in the direction of thedrag. Exemplary types of screens using a touch and drag gesture include:a ‘Category’ list; ‘Recent Searches’; ‘Favorites’; ‘Airport’; ‘AddressBook’ list; ‘Messaging—Inbox’ list; ‘Messaging—Outbox’ list; ‘Movies— .. . ’; ‘Events— . . . ; and ‘Preferences—Country’.

FIG. 60 shows the Zoom slider using a touch and drag gesture, inaccordance with the principles of the present invention.

As shown in FIG. 60, a user touches, holds, and moves their fingerwithout losing contact with the screen. In response, the zoom slidermoves up or down in the direction of the motion of their finger.

The map display uses a touch and drag gesture (panning) to enable theuser to change the viewing area of the map. To accomplish this a usertouches and holds; and moves their finger in any direction, withoutlosing contact with the screen. In response, the map moves in thedirection of the motion of their finger.

A zoom bar displays on the right side of the map on all non-navigationmaps. The user can change the zoom level by touching and dragging thezoom slider, or by selecting the +/−icons above and below the zoom bar.

Swipe/Flick—

A swipe or flick is a unidirectional gesture used to contact the screenin a quick swiping or flicking motion. The screen scrolls in directresponse to the swipe or flick of the finger in the same direction withspeed based on the speed of motion before release. The screen movementcontinues until speed decelerates or the user touches the screen to stopthe motion.

Horizontal Swipe/Flick—

A horizontal swipe is used for navigating to the next or previous itemof detail screens. The current screen will move in the direction of theswipe, and the next screen will appear one at a time. The motion willcontinue until the next screen is fully visible. This feature is used to‘page’ through “details” screens of the application.

FIG. 61 shows the user interface (UI) flow for a MOVIE . . .RESULTS/MOVIE DETAILS. Horizontal Swipe sequence: DOWN, GESTUREsequence.

Vertical Swipe/Flick—

A vertical swipe is used for a fast inertia-based scroll such as quicklyscrolling up or down a screen or list. The screen moves quickly in thedirection of the swipe and eventually slows down and stops. This gestureis used in the application to scroll up or down list items. An exemplaryvertical swipe sequence: DOWN, GESTURE. When the user gets to the top orthe bottom of the list, their screen displays a ‘bouncing’ animationthat signals to the user that they are at the top or bottom of the list,Screens supporting the vertical swipe gesture are classified by ‘searchresults’ or lists. Exemplary screens include: a ‘Category’ list; ‘RecentSearches’ Results; ‘Favorites’ Results; ‘Airport’ List; ‘AddressBook’/Contacts list; ‘Messaging—Inbox’ list; ‘Messaging—Outbox’ list;‘Movies—Now Playing, Coming Soon, In Theaters, Theaters, Search ResultsList; and ‘Events Results List.

In general the elements used on the screen to illustrate gestures mimicthe native illustrations gestures as much as possible.

FIG. 62 shows dragging up and down support use instead of a scroll bar.The personal wireless navigation system uses a floating bar (with notrack and no arrows at the top or bottom of the track) that illustratesproximity to either end of any list; e.g., search result list, RecentSearches list, etc.

When in the navigation screen, the user is able to drag up and down toswitch between the navigation view and the upcoming turn view.

If drag support is not available in the particular host device for thepersonal wireless navigation system then the scroll bar is present at awidth of, e.g., 24 pixels.

The swiping gesture is used to support scrolling back and forth through:details screens; POI search results; movie search results; event searchresults; recent searches and favorites; weather for each day; navigationscreens; look ahead screens; trip summary screen; and traffic summaryscreens.

The navigation application supports box-out/box-in andslide-in/slide-out transitions.

A box-out/box-in transition is used in response to leaving the main menuand going back to the main menu.

Leaving the main menu (box-out) to any of the immediate landing screens:navigation, local search, movies & events, messages, maps & traffic, andmy places.

FIG. 63A shows a box-out transition, in accordance with the principlesof the present invention.

FIG. 63B shows a box-in transition, in accordance with the principles ofthe present invention.

FIG. 63C shows a slide-in/slide-out transition, e.g., used in responseto moving from one screen and moving from search details, in accordancewith the principles of the present invention.

In particular a slide-in/slide-out transition is used when moving fromone screen with menu list to the subsequent screen if the landing screenis a screen with: menu; text entry and/or category selection fields;radio buttons; and check boxes. In the given example the transition isfrom left to right as one drills down, and from right to left as onegoes back.

A slide-in/slide-out transition is used when moving from a searchdetails screen to the next, if the next is, e.g.,: POI search details;favorites and recent searches; movie details; weather details; andnavigation screen. A slide-in/slide-out transition is also used ifmoving from a traffic screen to look ahead screen.

There may be transition exclusions. For instance, in the exemplaryembodiment there are no transition requirements for pop ups, waitscreens, display of maps, zooming in or out, or panning.

Help text is simplified and applied to areas of the application that maynot be intuitive to the user. Examples of these screens include: plantrip; movie search; event search; new message; and detour options

The personal wireless navigation system implements a device menu featurethat launches whether using the device soft ‘Menu’ key or devicehardware ‘Menu’ key. Specific elements of the device menu include theability to switch application, and show symbols (RIM devices); and theability to exit the personal wireless navigation system application(Windows Mobile).

Selecting an item from the Menu invokes the action in the Menu. Forexample, selecting ‘Navigate’ starts a navigation session, selecting‘Map’ downloads a map centered on the specified location, selecting ‘Addto Favorites’ saves the location information to Favorites, and selecting‘Close’ takes the user to the previous screen. If the user selects‘Close’ after entering text in a text entry screen, the applicationprompts an appropriate message, e.g., “Changes will be lost. Go backanyway?”

The personal wireless navigation system enables users to cut, copy andpaste text from other applications into the Navigator text entry fieldsand vice versa. The options for cut, copy and paste are available in theapplication ‘Menu’.

To copy or cut, the user is able to select the item by touching andhighlighting the selected text, selecting the menu, and selecting copyor cut. For Windows Mobile devices, the user touches and holds on thetext area to launch the cut, copy, paste dialog box.

To paste, the user touches the text entry field, selects menu, thenselects paste.

The following areas of the personal wireless navigation system supportcut, copy, and paste:

Navigation

-   -   Address    -   Intersection    -   Home/Edit    -   Work/Edit

Local Search

-   -   What

Movie Search

-   -   What

Event Search

-   -   What

Messaging

-   -   New Message/To    -   Place/Address    -   Place/Intersection    -   Message

Search

Maps & Traffic

-   -   Map Location/Address    -   Map Location/Intersection    -   Traffic/Address    -   Traffic/Intersection    -   Weather/Address    -   Weather/Intersection

My Places

-   -   Favorites/Add/Address    -   Favorites/Add/Intersection    -   Home/Edit    -   Work/Edit

Windows Mobile and Blackberry devices support multi-tasking, meaningthat when other applications are used, the Navigator application on thepersonal wireless navigation system continues to operate on the device.For Windows Mobile users, the application icon appears in the taskmanager. For Blackberry devices, the application icon appears in theswitch applications menu.

If the personal wireless navigation system receives a voice call duringa navigation or follow-me map session, Navigation continues to run inthe background, unless it is not supported by hardware or its carrier.If not supported by the device, if the user answers the call, thenavigation session is suspended until the voice call ends. Once thevoice call ends, the navigation session resumes (preferably by forcing arecalculate) including recalculating the route.

If the personal wireless navigation system is downloading a map when avoice call is received, the map download is terminated. When the userends the call, the user receives an appropriate pop-up message, e.g.,“Could not process your request due to voice call. Please try again”,along with the appropriate error code. When the user presses ‘OK’, themap downloading is retried.

When using a media player, the navigation or follow me map continues toupdate GPS. Voice prompts continue. However, the media player may bepaused for navigation announcements. This is dependent on the prioritysettings of the OEM. Alternatively, it may be a configurable feature ofthe personal wireless navigation system.

For all other applications, the navigator runs in the background, untilthe user exits the application running in foreground, or pulls thepersonal wireless navigation system to the foreground. Voice prompts areheard upon upcoming maneuvers or announcements.

The personal wireless navigation system provides an alarm clock. Inoperation, when the navigator application is in the foreground, uponreceipt of an alarm event, the alarm event goes to the foreground andthe navigator application runs in the background, providing voiceprompts until the user takes action to dismiss the alarm event. Upondismissal of the alarm event, the navigator application returns to theforeground.

If during a navigation session the personal wireless navigation systemgoes outside a service area, as long as the user does not go off route,the application continues to provide turn-by turn voice prompts. If theuser goes off route, the application tries to recalculate, but pops upan error message.

The personal wireless navigation system application terminates upon aninsufficient memory event. For instance, a pop-up error message isdisplayed indicating “insufficient system memory or resources” or thelike.

A low battery event may impact GPS capability. In such a situation, thepersonal wireless navigation system may not be able to get a fix,impacting searching, mapping, and navigation based on GPS location. Thepersonal wireless navigation system displays a low battery event to theuser and preferably informs them of the impact to the GPS capability.

The personal wireless navigation system application terminates upondevice power off, device reset, or factory reset.

The navigation application continues to operate when a universal serialbus (USB) device is connected or disconnected.

The personal wireless navigation system application detects when ahardware keyboard is open. If the hardware keyboard is open, thesoftware keyboard does not launch when the text entry field is selected.

Instead, the user is permitted to enter text with the hardware keyboard.On the other hand, when the personal wireless navigation systemapplication detects that the hardware keyboard is closed, the softwarekeyboard launches when the text entry field is selected, permitting theuser to enter text with the soft keyboard.

When the navigator application of the personal wireless navigationsystem is in the foreground, upon receipt of an incoming e-mail event,the user has the option to immediately respond to the event. If the userdoes not immediately respond, the navigator application continues to runin foreground, providing voice prompts. If the user opts to view theincoming e-mail, the navigation application continues to run but inbackground, continuing to provide voice prompts as required. Once theuser dismisses the e-mail application, the navigation applicationreturns to the foreground.

When the navigator application of the personal wireless navigationsystem is in the foreground, upon receipt of a short messaging system(SMS) event, the user has the option to immediately respond to the SMSevent. If the user does not immediately respond, the navigatorapplication continues to run in the foreground, providing voice prompts.If the user opts to view the incoming SMS message, the navigationapplication continues to run in the background, continuing to providevoice prompts as required. Once the user dismisses the SMS application,the navigation application returns to the foreground.

The navigation application of the personal wireless navigation systemcontinues to operate when ActiveSync starts or stops.

During a navigation session, if the user selects the ‘Back’ softkey orhardware key and selects ‘Yes’ when receiving the pop-up “StopNavigation? Are you sure you want to stop navigation?” Navigation stops,and no GPS fixes are taken. Navigation also stops when the personalwireless navigation system reaches the navigated destination and remainsat the destination for more than a given significant amount of timetypically unrelated to traffic, e.g., for more than 10 minutes.

If the navigation application is running in back-ground, and thelocation information has not changed for a given significant amount oftime, e.g., 10 minutes, the application invokes a pop-up message “Do youwant to end Follow-Me mode? Yes/No”; user selects Yes. Once the pop-upis displayed, and the user has not selected, navigation is suspended.

The personal wireless navigation system Navigator applicationintergrates with an ‘AddressBook’ or ‘Contacts’ application of thedevice. ‘AddressBook’ or ‘Contacts’ is a menu item within theapplication. When the application prompts the user to select a locationas a starting point, destination, or center point for a local search ormap, the personal wireless navigation system enables users to select alocation from the device ‘AddressBook’ or ‘Contacts’ from the LacWiz.

The personal wireless navigation system has the capability to launchfrom the ‘AddressBook’ or ‘Contacts’ application. If the user selects acontact within the ‘AddressBook’ application, the LBS functions areavailable as a menu option. If more than one Navigation application ispresent on the personal wireless navigation system device, the Navigatorlocation based system (LBS) functions take priority within the menu.

FIG. 64 shows an example of LBS functions available as a menu optionwhen a user selects a contact within the ‘AddressBook’ application, inaccordance with the principles of the present invention.

When selecting AddressBook within the Navigator application, theapplication searches all address fields within AddressBook for allavailable addresses for the contact. Priority to first search Home, thenWork addresses. If only one address is available when the user selectsthe contact, ‘selecting’ initiates the action (Navigate, Map, etc.) Ifboth address fields are available, a pop-up displays both addresses forthe contact, as shown in FIG. 65. Selecting the option initiates theaction (Navigate, Map, etc.)

When selecting ‘AddressBook’ within the Navigator application forsending a ‘Place Message,’ the application displays the contact list,allowing the user to select multiple entries. If multiple phone numbersare available for a contact, the application displays all availablephone numbers,

The personal wireless navigation system interoperates with a ‘Calendar’application of the device when a ‘Calendar Location’ field contains anaddress or general information. If the location field of ‘Calendar’contains an address or general information, the user has the followingoptions available in the ‘Calendar’ application menu: Get Directions To. . . , Map, and Local Search. If more than one Navigation applicationis present on the device, the personal wireless navigation system'sNavigator LBS functions take priority within the menu.

If the address information is available in the Calendar location field,the personal wireless navigation system parses the address data and mapsit appropriately to the Get Directions To . . . (Navigation UI Flow),Map (Map UI Flow), or Local Search (Local Search UI Flow) functions. Theapplication launches, finds the address, and either starts theNavigation session, maps the location, or goes to the Local Searchscreen to select a category. For Local Search, the address or locationappears in the “Where” field.

If general information such as “Starbucks” or “TeleCommunicationSystems” is stored in the Calendar location field, the user has theoption to Get Directions To . . . (Navigation UI Flow), Map (Map UIFlow), and Local Search (Local Search UI Flow) functions. However, ifaddress information is not available, the application launches the LocalSearch screen with the general information in the “What” field.

If no information is available in the location field and the userselects one of the options: Get Directions To . . . ; Map; or LocalSearch, the application launches to the main menu of the personalwireless navigation system.

The ‘Back’ hardware key returns the user to the previous screen or hidesthe keyboard. If the user has entered text within a screen and selectsthe ‘Back’ key, the personal wireless navigation system displays themessage “Changes will be lost. Go back anyway?”

The ‘Send’ hardware key initiates a ‘call’ function. If the user is in a‘Detail’ screen, and the phone number information is provided, selecting‘Call’ or the ‘Send’ hardware key initiates a call to that location. Ifthe user is in a results screen the results item is highlighted. If the‘Call’ or the ‘Send’ hardware key is selected, the Navigationapplication displays a pop-up to either call the location or anothernumber. If the user is in any screen having no item highlighted, yetselects the ‘Call’ or ‘Send’ hardware key, the phone dialer of thepersonal wireless navigation system is invoked.

Selecting the ‘End’ key places the Navigation application in thebackground and appropriately multi-tasks. For low tier devices,selection of the “End” key ungracefully exits the Navigationapplication.

Selecting and holding a ‘Power’ key (if separate from the device's ‘End’key) suspends navigation and closes the Navigation application.

Selecting a ‘Home’ hardware key places the Navigation application of thepersonal wireless navigation system device into the background, andtakes the user to the device's main menu (for Windows Mobile devices.)

Selecting volume keys while in the Navigation application of thepersonal wireless navigation system launches the Navigation volumescreen, allowing the user to change navigation volume settings.

Touching in the text entry field invokes the keyboard. When the usertouches a text string, the cursor is positioned behind the character orat the blank space that the user touched. If the user touches the textentry field outside of the text, the cursor is positioned behind thelast character. The proper keyboard is displayed based on the contentsof the text entry field.

Search/Find fields (qwerty or alpha numeric) include: Address/Street(qwerty or alpha numeric); Address/City (qwerty or alpha); Address/State(qwerty or alpha); Zip/postal code (qwerty or alpha numeric); and Phonenumber (numeric),

The ‘Return’ key moves the user to the next text entry field. Selectionof ‘Return’ at the last text field produces no action. In the PlaceMessaging ‘Message’ field, selecting ‘Return’ moves the user to the nextline in the field.

The personal wireless navigation system Starts-Up instantly, launchingthe main menu. In particular, the splash screen is presentedimmediately, followed quickly by the main menu, providing the perceptionof an instant start-up.

Each time the personal wireless navigation system is started, theNavigation application does a “Follow Me Map”—the result being the newmain menu look which shows users where they are. At the same time themain menu functions are displayed (minimum set is Navigation icon, LocalSearch icon, plus search box).

The personal wireless navigation system acquires real time local trafficinformation and weather conditions. This is particularly important forusers with advanced devices and high tier devices, where the personalwireless navigation system takes advantage of a large screen size andbetter resolution. Thus, the personal wireless navigation system:

-   -   Displays users' current location to help them get oriented.    -   Provides current weather conditions, average gas price for        regular gas in the local area, and provides an option for        overlaying traffic. These features take advantage of a        presumption that the user launched the Navigation application of        the personal wireless navigation system to search for a place or        event and to be guided accordingly.    -   Provides a search box where users type or speak what they are        looking for.    -   Provides icons/buttons for all relevant functions.

This main menu layout makes the personal wireless navigation system morefunctional, appealing, and therefore more useful than Google Maps™,which only shows a map of the user's current location, and better thanconventional portable navigation devices (PNDs) and some in-carnavigation systems, which typically show the map of users' lastdestination. The main menu layout helps users access some localpoint-of-interest (POI) information, traffic information, gas prices andlocations, and weather information, faster than conventional techniques.

Preferably the main menu is displayed within 5 seconds or less from thetime that users launch the application; regardless of whether there aresplash screen requirements or not. The main menu comprises four generalframes as illustrated in FIG. 66.

In under 10 seconds after launch of the Navigation application of thepersonal wireless navigation system, a map of the area around the users'current location is presented. If longer than 10 seconds, launchdisplays a map of the last GPS location until the location is updated.Address information does not display in the header.

Within 5 seconds (or less) after launch of the Navigation application ofthe personal wireless navigation system, buttons/icons are displayed forall major functions: NAV, Search, Place Messaging, etc.

In under 15 seconds after launch of the Navigation application of thepersonal wireless navigation system, a header showing relevant currentinformation, e.g., weather, gas prices, etc., is displayed.

In under 5 seconds after launch, a search box is presented where theuser can enter text or speak the term.

Shortcut keys are configurable for presentation on the left or rightedge of the display.

In under 5 seconds, to accommodate small tier devices (e.g., standardphones), as soon as the Navigation application is launched, the map of“You Are here” shows on the screen. A push button at the bottom saying‘Press Down for Functions’, displays a 3×2 grid icon main menu. Userscan press up to return to the map of where they are.

When the user launches the Navigation application, the personal wirelessnavigation system gets a fix for the current location under 10 seconds.The map of current location is displayed with user's current location innder 15 seconds after launch and upon successful location fix. Currentweather conditions, and/or average local regular gas price around theusers' current location, is obtained and displayed in under 15 secondsafter launch and upon a successful location fix.

When the user taps on the marker for the current location, the screendisplays a menu of options as shown in the table of FIG. 67.

The user zooms in and out or snaps to the appropriate zoom level byusing the zoom toolbar on the map. The user pans by tapping on adifferent area on the map, flicking or dragging on the map, or using thescroll buttons/trackball.

When the user double taps on the same spot on the map (within 500milliseconds of one another) the screen displays a menu of options asshown in the table of FIG. 68.

When the user selects/taps the ‘Traffic’ button to hide/show real timetraffic flow and incidents (if any) that are overlaid on the map, bydefault, traffic is always shown.

When the user selects/taps the ‘Gas’ Button displaying local average,and the personal wireless navigation system conducts a local search forgas stations around the current locations, a list of gas stations aroundthe current location is displayed.

When the user selects/taps the ‘Weather’ button, the screen obtains anddisplays the current and forecast weather (e.g., a 6 day forecast) forrelevant local areas.

When the user selects/taps the search box, types or speaks the businessname or category, search results are listed after the necessarytransition screens are displayed.

When the user selects/taps ‘Map’, the location of the first 10 (or 20)search results are displayed on the map.

When the user selects/taps one of the search results, a POI detailsscreen is displayed.

When the user selects/taps the ‘Search’ button, the personal wirelessnavigation system prompts the user to select from POI search, moviesearch, or event search.

When the user selects/taps the ‘Navigation’ button, the personalwireless navigation system prompts the user to select a destinationfrom: Recent Places, Favorites, Address Book (high end phones), Address,Airport, Home, Work, or Plan Trip.

After the route has been calculated and the transitions screen(s) havebeen displayed, the Map automatically zooms in (or snaps to) the defaultzoom level for displaying the start of the route.

For car navigation, the personal wireless navigation system alsoswitches from top view to perspective view after it zooms in (orswitches to perspective view if the ‘zoom in’ effect is patent protectedby a 3^(rd) party). For Pedestrian navigation, the view mode stays at 2Dafter the personal wireless navigation system zooms in.

For the reduced feature version of the personal wireless navigationsystem (e.g., “AB v5”), when the user selects/taps the ‘Navigation’button, AB v5 prompts the user with information for purchasing(unlocking) a full featured version of the personal wireless navigationsystem (e.g., including GPS navigation).

If the personal wireless navigation system cannot fix a location, thepersonal wireless navigation system displays a map of the United States(or Europe).

The personal wireless navigation system supports night mode. Some colorsmake it difficult for drivers to see the details of the 3D and 2D atnight time, where the dark background makes the screen relativelybrighter. In particular, the personal wireless navigation system uses adifferent set of color palettes at night time to make the vector mapsmore legible at night time. Moreover, the personal wireless navigationsystem uses a table of sunset and sunrise times to switch to night modewhenever the 3D and 2D navigation maps are rendered.

Alternatively, the night mode features may be activated only through amanual setting under configurable navigation options, including anoption for changing from Day Mode to Night Mode. This setting is asticky setting. Each time a route is calculated, the application willlook up a time table and based on the current time either render thevector maps in day or night mode. Moreover, the personal wirelessnavigation system provides users with a configurable time table andbased on the current time as compared to the configurable time table,either render the vector maps in day or night mode.

Each time the personal wireless navigation system is started theapplication does a “Follow Me Map” which achieves two things: First, itgives the personal wireless navigation system the main menu look; andSecond, it obtains the users' current location to support other productfunctionality and usability requirements. The location acquisitionprocess is performed in under 10 seconds after launch, if the userlaunches the application in a new area.

The personal wireless navigation system automatically completes the‘State’ portion of the address as soon as possible, when possible, asthe user enters a street address. Moreover, local airports are providedfirst if a user is designating an airport as a destination, startingpoint, or center point for a map or search.

The personal wireless navigation system uses any one or combination ofservices such as Cell towers, PDE, GPS, Wi-Fi, etc., to determine users'location once they start the application, in 10 seconds or less.

When a user speaks a business type, the personal wireless navigationsystem expedites the speech-to-text conversion process by eliminating orreducing the wait time for the first screen, as shown in FIG. 69.

If none of the above services are available, an error message islogged/reported back to the personal wireless navigation system server.No error message need be displayed on the device screen unless the userexplicitly initiates an LBS request that requires getting a locationfix.

The personal wireless navigation system provides internationallocalization support by enabling a user to enter addresses in theappropriate format for a given country. Each time the personal wirelessnavigation system is launched, if its user is in a different country,the address entry fields are listed and ordered based on how addressesare entered in the current country. The country and state (province,region) fields are populated in the event that users choose to navigateto, search around, or map a location in that country/state (as that hasa higher degree of probability). The personal wireless navigation systemmay obfuscate certain POI category names, or access to event search andmovie search in each country. Each time a user starts the personalwireless navigation system and the application detects that the locationis outside the “home” country, the personal wireless navigation systemchecks to see if country support is available. If it is, it uses thecoordinates to automatically change the country profile used for thatsession (if not changed since last time), and to format the addressentry field for that country. The appropriate set of navigation featuresavailable to users, such as ‘traffic’ menu settings, or traffic gauge,are determined for the new country.

Some functionalities of the personal wireless navigation system areconfigurable, such as traffic, navigation view, movies and events,weather and languages. Thus, for certain brandings of the personalwireless navigation system, the functionalities may not be exposed tothe user.

For instance, there is no need to display traffic enabled navigation ifthe branded version of the personal wireless navigation system does nothave access to real time or historical traffic. Configurable show/noshow parameters of traffic include: traffic setting field; trafficsetting screen; traffic gauge bar in navigation screen and look aheadscreen; Traffic delay column with or without value; Traffic summaryscreen; Access to traffic summary screen via LSK on Trip Summary oroptions menu in the navigation screen; Menu option for listing trafficincidents, details; Delay time per segment in detour around segmentlanding screen; ‘Incident’ and ‘Congestion’ choices in the Detour typeselection screen; and Traffic Alert icon. With respect to Trafficoverlay on maps, the following parameters are configurable to show/noshow in any given branded implementation of the personal wirelessnavigation system: Traffic as an option under Maps; Menu option forhiding and un-hiding traffic; and Menu option for listing trafficincidents, details.

For some brands of the personal wireless navigation system, 2D and 3Dviews with sliding maps may not be optionally included, depending upwhether or not its users have to pay per Mb for data access.

The navigation view setting field and/or the navigation view modeselection screen may also be a carrier, OEM and/or provider configurableparameter to be shown to the user.

With respect to movies and events screens that may be configurably shownto a user, the following screens are configurable by the carrier, OEMand/or provider to be shown to the user: Movies & Events main menuselection; All sub menus related to movies; All sub menus related toevents; Access to movie search from the options menu of a POI detail,Favorite, or Recent Search; and Access to event search from the optionsmenu of a POI detail, Favorite, or Recent Search.

Regarding weather screens: Weather as an option under Maps may be shownor not shown based on the configurable status set by the carrier, OEMand/or provider. Similarly the Language of the personal wirelessnavigation system may be a configurable item.

If a user needs to enter an address in a different country, they may goto a ‘Country Selection’ field. The personal wireless navigation systempreferably does not update parameters in the background, until theuser's GPS location is indeed confirmed to be in that different country.A country list only includes supported countries. If a user types acountry that is not in the list, then a pop up informs the user that ‘Nosupport is available for the selected country’. This includes allcountries without map data. Countries are listed if map data isavailable but POI data is not, so that in special cases, the personalwireless navigation system can navigate users through such a country(Country B) in order to get them to a destination in another country(Country C), where the starting point was in yet different country(Country A).

If users are using the personal wireless navigation system to navigatethrough a country/region that ABN does not support, i.e., where no mapdata or route data is available, (and yet data roaming is available),then the personal wireless navigation system provides limited visual andaudible support to guide the user to the destination.

The list of the countries includes the international country code as aprefix (one or two letters), followed by the spelling of each country asit is pronounced in the language setting of the application, followed bythe spelling of that country, as it is done by local people. This lastexample is done to help familiarize users with the most likely spellingthat they are about to encounter in airports, roads, etc.

EXAMPLES

-   -   If an English speaking American travels to Germany, the country        field will show Germany as:

Germany

-   -   If a French speaking Canadian travels to Germany, the country        field shows Germany as:

Aleman

The default value for what units of measure the personal wirelessnavigation system uses when users move to different countries is set aseach brand of the personal wireless navigation system is prepared.

For some brands, the default is set to keep ‘Use Current Units ofMeasure’, such that when users select a different country where theunits of measure of distance and/or date formats are different fordisplaying, e.g., movies and events, the results are displayed in thesame units of measure. For example, an exit sign may state “1 kilometerahead,” but the navigation application would still display and announce“0.6 Miles” to help its user relate to it more effectively. The userscan select ‘Preferences’ to change either to metric or British units.

For some brandings of the personal wireless navigation system, thedefault is set to keep Use Local Units of Measure′, such that when usersselect a different country where the units of measure distance, and dateformats for displaying movie and events are different, the results aredisplayed as they are in that country. For example, if an exit signstates “1 kilometer ahead,” the navigation application would announce “1Kilometer” to help its user relate to it more effectively.

The search engine searches for category names even if the user specifiesa common name and search within All Categories′. The user is able toenter a common name in the “What” field while searching under “Allcategories”, and the search engine returns all POIs that include theword that was entered in the ‘What’ as part of the POI's respective‘Category’ description, regardless of whether the common name is part ofthe POI name or not. As an example, a user types ‘Coffee’ in the “What”parameter, and the search engine lists all “Starbucks” establishments,as the category for this POI is “Coffee Shops”, even though the name‘coffee’ is not part of the POI name (It is not listed as “StarbucksCoffee” in NAVTEQ Database—it is just listed as “Starbucks”).

The personal wireless navigation system supports fuzzy and partialsearch. For instance, the personal wireless navigation systemautomatically disambiguate strings entered by a user and conducts asearch in instances where the user types a partial string or makesslight spelling errors.

The search engine of the personal wireless navigation systemintelligently guesses what the most popular terms that the user wasintending to type in the event that the user made a spelling error oronly entered partial text. The following table illustrates generalexamples of an input text string and how the personal wirelessnavigation system automatically disambiguates the same, withoutprompting the user to do so.

Typed Word Returned Options Piz Pizza Hut Pan Pizzeria PanPiz PanPizzeria Pan Piz Pan Pizzeria Pizzas Pizza Hut Pan Pizza Pissa PizzaOland Öland

The POI category and subcategory is preferably added on behalf of therelevant partner/operator/brand in real time. The customer partner orenterprise customer of partner supplies an electronic list of POI andcategory name, and it is incorporated into the appropriate Category/Subcategory directory. The TeleCommunication Systems/NIM server providesthe infrastructure to integrate and classify the supplied POIcategory/subcategory in real time with a frequency equal or less thanonce per day. The POI list is geo-coded if not already.

For instance, an operator supplies a list of authorized resellerselectronically. The POI list, e.g., “XYZ authorized resellers” isuploaded, in the appropriate category/sub category list. The suppliedPOI list is then geo-coded, and then uploaded and classified in thedatabase—preferably no more than once per day.

The personal wireless navigation system implements user defined tags of‘Favorites.’ In particular, the user may tag one or more ‘Favorites’ sothat they can enter the tag name in the search box for faster recall offavorites with the same tag. In this way, the personal wirelessnavigation system helps a user find a bookmarked ‘Favorite’ faster, asopposed to requiring them to recall the first few letters of thefavorite POI that they are trying to locate in a favorites list.

A user can create a tag name and assign it to one or more favorites,such as ‘favorite restaurants’, ‘favorite bars’, etc., and organizetheir favorite POI in logical groups.

Whenever the user synchronizes ‘My Places’ with the navigation centralserver website, the ‘Favorites’ with tags is synchronized such thatusers can also search for favorites by entering the tag name.

Each time a user adds a favorite, the personal wireless navigationsystem gives them the option to select a tag name for that favoriteplace. Users can select from previously entered tag names or type a newone. Similarly, each time a user edits a favorite, the personal wirelessnavigation system gives them the option to edit the tag name. If a userviews their list of favorites, the tag name for each favorite is listedin tandem. If the user sorts the list of favorites in alphabeticalorder, the favorites with the same tag name are sorted together. If theuser views the place details of a favorite having a tag name, the tagname appears at the bottom, before the Category classification (if aPOI).

The present invention appreciates that drivers with kids in the backseat might like to know how far the next rest stop is when traveling.Therefore, in the personal wireless navigation system, ‘Rest Areas’ isadded as a distinct POI category. Furthermore, ‘Rest Areas’ is a defaultPOI that shows along the route during navigation. For metro and urbanareas, especially in Europe, display of public restrooms is as relevantto pedestrians as it is to ‘Rest Areas’ to drivers.

The present invention also appreciates that users of the personalwireless navigation system desire knowledge of the location of publicWi-Fi Hot Spots. This is particularly relevant as more complimentary andpremium hot spots are rolled out. Also, as more phones support dualmodes (3G/2.5G and Wi-Fi), more people can explicitly choose Wi-Fi toplace a phone call via VoIP+Wi-Fi Solutions. Free Wi-Fi Hot Spots arerare in Europe, so users are more likely to want to find Hot Spots thatare part of their wireless network account. To satisfy this unsolvedneed, the personal wireless navigation system includes a distinctcategory called Wi-Fi Hot Spots. A feed for Hot Spots is preferablyobtained, where the Hot Spot locations are updated, e.g., monthly.

When searching for hotels, for each search result, the personal wirelessnavigation system obtains and provides pricing for the hotel POIsrelevant to that evening, or when the navigation would bring the user toeach particular hotel or other POI. The price is displayed as $NNN.NNand the results are listed similar to how gas prices are displayed.Hotels without an available price are listed similar to how gas stationswithout available price per grade are listed. Helpfully, the personalwireless navigation system displays ‘Sold Out’ instead of a price forhotels that it determines are sold out for that day or evening.

For J2ME devices where JSR-293 is available instead of JSR-179, thepersonal wireless navigation system utilizes JSR-293 Location API 2.0 toobtain location information and GPS fixes.

The personal wireless navigation system permits a user to search formovies and events, and once they found the desired movie or events, theyare able to search for theaters and venues hosting them. The centralserver providing navigation services also preferably provides a link tothe official movie poster and/or movie trailer.

The personal wireless navigation system provides phone numbers of themajor roadside service providers, including the ability to find thenearest roadside service provider near to the current location, A userwith a stranded vehicle is then able to either request access to desiredservice center if they are a member of one, or get fast access to alocal roadside service providers. A fee may be associated with thisservice feature.

As an example, a user breaks down when traveling. The user wants to findsomeone nearby who can supply roadside service (may involve a tow). Thepersonal wireless navigation system modifies the current “Emergencyservices” category search to display a phone number (and preferablyconnecting to the phone number) which provides a link to a suitable towtruck and/or other emergency services. The coordinates for the userscurrent position (latitude, longitude) is also displayed on the screenenabling users to report the coordinates to the dispatch person. Thepersonal wireless navigation system preferably includes a reversegeo-code to a closest street address of the current locationcoordinates.

Once the personal wireless navigation system displays POI searchresults, either the footer or options menu provides users with theoption to map all search results.

The map is always centered on the location specified in ‘Where’. Asshown in FIG. 70, the user can tap on any POI to see a brief descriptionof the POI. A second tap provides the user with the POI detail screen.If the user zooms out, the personal wireless navigation system displaysadditional POIs, and the personal wireless navigation system downloadsthe next batch, when necessary. This functionality may be excluded fromuse on devices with smaller screen sizes if desired.

A user may view a map of search results and friends together on a map,providing a visual reference for geo poking capabilities. Rather than belimited to only a map of the highlighted search result, the user is ableto view their friends' location and relevant POIs on the same map. Thisfunctionality may be excluded from use on devices with smaller screensizes if desired.

The personal wireless navigation system is able to read maps from eitherNAVTEQ or TeleAtlas. If an international edition of the personalwireless navigation system needs to provide maps for two borderingcountries such that the map for one country is supplied by NAVTEQ whilethe other one is provide by TeleAtlas, the personal wireless navigationsystem continues to render maps with very little disruption on thedisplay screen.

The personal wireless navigation system website provides users with theability to report problems with maps, including wrong street names,wrong business name, etc., through the central server website.

Wherever necessary, the personal wireless navigation system uses the 3Dengines of the hardware such as OpenGL ES 1.0 to support 3D graphicswith improved performance—if and only if the architecture for thepersonal wireless navigation system mobile application can benefit fromthem.

Some features may be disabled by a non-full-featured edition of thepersonal wireless navigation system as compared to a full-featuredproduct. For instance, a non-full-featured edition of the personalwireless navigation system may disable turn-by-turn guidance, reroutingguidance, detour features, and traffic aware routing. Other features maybe enabled in both, e.g., Instant On, Map Main Menu, InternationalLocalization, POI Search, Movies & Events Search, Weather Search,Traffic Search, Synching with Website, Place Messaging (for both mobile& Web), GeoPoke, 411 Interface, App-to-App, Web-to-App, andOpt-in/Opt-out.

Up/Down Thermometer Cartography Detail Control

A visual thermometer or volume up/down type bar may be implemented toenable the user to control the level of detail displayed on thenavigation map. As an example, when the control knob is visually placedall the way down, the most limited cartography would be displayed. Then,as the user increases the ‘volume’ of the up/down thermometercartography detail control, the available levels of detail areincrementally displayed to the user, up to a maximum ‘up’ causingdisplay of the most detailed information available (e.g., street view,3D, etc.)

In the disclosed embodiment a mid-way position of the up/downthermometer-like cartography detail control, traffic may be displayed tothe user on the navigation map. This provides instant flexibility to theuser.

In an alternative embodiment, a user who might want a simpler visual maybe presented with a one-touch control. And those users who might enjoymore detail may want to instantly see more detail (e.g., around a turnthey may quickly want some greater detail displayed), then may dial theknob up to a maximum position for a brief time, gain knowledge from theadditional detail shown on the navigation map, then dial the cartographydetail control back down to cause display of less detail on thenavigation map.

Faster Rendering of Maps

The system design of Tile Maps in AtlasBook v5 is now described.

AtlasBook products prior to v5 have relied on maps that were generatedto fit the screen of a device for a particular coordinate and zoomlevel. This type of map works well for situations when user interactionis minimal and thus the central point and zoom level of the map is notexpected to change often. However, this design does not work well ondevices such as those with touch screens, causing more maprender/download cycles as the user has an increased ability to interactwith the map. These pan/wait/download cycles hinder the user experience.Version 5 addresses this issue by introducing a tile-basedimplementation for raster maps. This document details the system designfor this solution, including the client- and server-side components.

The client-side component comprises two main layers: a graphical UIlayer (orange box) and a data management layer (blue box). Both of theselayers are described in full detail.

Faster rendering of maps is accomplished in v5 by the adoption of a TileMaps architecture. The Tile Maps implementation comprises threesections: (1) App layer (how the user interacts with the new mapcontrols from various parts of the application); (2) Platform-specificTile Maps UI layer (the map control itself, providing a host of relevantmap-related features); and (3) Platform-independent data managementlayer (the underlying Tile Maps architecture responsible for providingdata to the Tile Maps UI layer).

The app layer is responsible for deciding how to use the map control toprovide the user with all of the v5 features relating to Tile Maps. Thisincludes the ability to display a map, center a map, pan/zoom, rotate,ID, show POI, show “Where Am I?”, traffic and Follow Me. These are thefunctional requirements of the Tile Map system as seen from the user'sperspective.

The UI layer comprises all the functionality associated with drawing maptiles and responding to user interaction. This includes but is notlimited to sending prioritized tile requests to the lower layer, drawingdownloaded map tiles to the screen, user interaction with the map, anddisplaying place data on the map. This layer is implemented in a waythat is customized to each platform in order to match the platform'slook and feel/conventional user interaction as well as optimize drawingperformance by making use of native platform features.

The client has a multi-level cache for the tiles, indexed using thetile's coordinates and ordered based on last use. This system allows fora more optimal experience by storing unused tiles in a file-basedstorage to reduce memory footprint, while keeping relevant tiles inmemory for faster recall as the user pans the map. In addition, theclient has an algorithm for determining the tiles to download as well asprioritizing the queue of tile requests. This is necessary due the factthat as the user pans the map, tile priority changes and some pendingtile requests may need to be de-prioritized or thrown out altogether.

Previously, maps were rendered on the server, along with the time basedinformation like traffic flow, upon request. Tile maps, in contrast, arerendered by a “dedicated” tile server and do not have time-basedinformation such as traffic stored on them. To display this dynamicinformation, there is a need for overlays for features such as drawingtraffic and navigation routes.

These tile layers are drawn as a transparency over the map tiles. Thisway if the user were to disable an overlay, the base tiles would notneed to be downloaded again. Currently the list of server-renderedoverlays comprises traffic and route polylines.

The engine is able to select from any number of tile sources, eitherinternal or from external vendors, such as Microsoft Virtual Earth (inV5, the only map source supported is the NIM Dynamic Tile Server (DTS)).This is controlled by retrieving a NIM Service URL on initializationwhich determines the URL and request format used for tile downloads.

The description of tile map rendering includes a description offunctional requirements, which is where system-level test cases arederived. The overall system architecture is then described, as arevarious system analysis topics. Use cases and functional walkthroughsfollow, and the specifications of various sub-systems are outlined.

The top-level functional requirements for Tile Maps are broken down byuser-level function. Tile Maps is a very visual function and ascreenshot or drawing is often the best way to convey detailedrequirements. The Maps UI flow includes numbered screens.

Requirements for general map functionality for the server include: zoomlevel; tile size (for labeling); region (e.g., US, CAN, EU, etc.);various location densities (various location densities (e.g., metroareas vs. suburban vs. sparse); supported dot per inch (DPI) values(e.g., 96 or 192); and supported locales.

Map features that are displayed include, but are not limited to: roadclasses; road names; address ranges; railroads; ferry routes; buildingoutlines; state borders; direction of traffic arrows; city center icons;city, state and country names; highway shields; area features likeoceans, rivers, lakes, parks, airports, shopping malls; area names;Languages to be used in labels; Widths and borders of visible mapfeatures; Colors of map features; Stipples to be used for area features;Font sizes, colors, borders, and anti-aliasing; Highway shield density,colors, and sizes; Road, city, area label densities; Traffic flowcolors, borders, and widths; and Route line colors, borders, and widths.

The Map Tile Server returns map tile images via HTTP GET request. TheMap Tile Server returns transparent traffic overlay tile images via HTTPGET request. The Map Tile Server returns transparent route overlay tileimages via HTTP GET request. The Map Tile Server supports an applicationname of “map” for map tile images, an application name of “traffic” fortraffic overlay tile images, and an application name of “route” forroute overlay tile images.

The Map Tile Server URL supports a locale in the query string specifiedby a field named “lc”, The Map Tile Server only supports a locale valueof “en-us”, and may support other locale values. The Map Tile Server URLsupports an image format to be requested in the query string specifiedby a field named “fmt”. The Map Tile Server URL supports an image formatvalue of “PNG”, and may support other image format values. The Map TileServer URL supports a specific resolution to be requested in the querystring specified by a field named “res”, The Map Tile Server URLsupports resolution values of either “96” or “192”, and may supportother resolution values. The Map Tile Server URL supports a zoom levelto be requested in the query string specified by a field named “z”, andsupports zoom level values of 2 through 18 for 256×256 map tiles. TheMap Tile Server URL supports zoom level values of 3 through 19 for128×128 map tiles, and zoom level values of 4 through 20 for 64×64 maptiles. The Map Tile Server URL supports a specific tile for a zoom levelto be requested in the query string specified by the fields named “x”and “y”. The Map Tile Server URL supports a tile size to be requested inthe query string specified by a field named “sz”. The Map Tile ServerURL supports tile size values of “64”, “128”, and “256. The Map TileServer URL supports a version to be requested in the query stringspecified by a field named “v”. The Map Tile Server URL uses the versionof the request and for cache invalidation. The Map Tile Server URLsupports a route overlay tile for a given route ID to be requested inthe query string specified by a field named “rid1” or “rid2” in the caseof a second route ID being requested. The Map Tile Server URL supportsroute overlay tile route IDs as a base64 encoded string of the binaryroute ID returned in an NB Server navigation reply. The Map Tile ServerURL supports route color to be specified by a field named “rc1” or “rc2”in the case a second route ID being requested.

The Map Tile Server URL supports route color values to be specified inthe following format: “RRGGBB”, where: (a) RR is an uppercase 2character hex octet from 00-FF signifying the red channel, (b) GG is anuppercase 2 character hex octet from 00-FF signifying the green channel,and (c) BB is an uppercase 2 character hex octet from 00-FF signifyingthe blue channel. The Map Tile Server URL supports route color values tobe specified in the following format: “RRGGBBAA”, where: (a) RR is anuppercase 2 character hex octet from 00-FF signifying the red channel,(b) GC is an uppercase 2 character hex octet from 00-FF signifying thegreen channel, (c) BB is an uppercase 2 character hex octet from 00-FFsignifying the blue channel, and (d) AA is an uppercase 2 character hexoctet from 00-64 (decimal 0 to 100) signifying the alpha channel whichcontrols transparency. A value of 0×00 (0%) signifies that the route isfully opaque (no transparency). A value of 0×64 (100%) means that theimage is fully transparent (invisible!). The Map Tile Server URL returnsa 204 (success—no content) status code for traffic overlay tile requestswhere there is no traffic info to be displayed in the map. The Map TileServer URL returns a 204 (success—no content) status code for routeoverlay tile requests where there is no polyline to be displayed in themap. The Map Tile Server URL returns a 404 (page not found) status codefor invalid or unsupported URLs based on the above requirements. The MapTile Server supports detailed maps for all desired countries.

Different wireless devices each have their own device-specificfunctionality. Parameters which vary from device to device include:Height and Width of the relevant display (in mm); DPI of the relevantdisplay; Tile size best suited to the relevant display; Resolution/DPIbest suited to the relevant display; Keyboard type or types associatedwith the relevant device; and Keyboard shortcuts to be used for therelevant device.

The map supports fast display and panning of tiled maps. Tiled maps acton all types of inputs that a device is capable of for panning, zooming,tracking one's own position, and searching for POIs.

The map downloads tiles asynchronously and displays them as they becomeavailable. Downloading map tiles is done in the background and is notlimited by the user's interaction with the map. Tiles are displayed assoon as they become available. This applies whenever the map is zoomed,panned or rotated. Upon zoom in/out existing map tiles are scaled andused as placeholders until the new map tiles are available. If a tile isnot available then a placeholder graphic is displayed in the confines ofthe tile. This graphic MAY be specific to each product. Graphic shouldbe non-obtrusive. The user is able to pan the map by dragging thestylus/finger (touch) or D-pad (non-touch) on the map. The user is ableto zoom in and out, with a preconfigured minimum/maximum zoom level.

Preferably the map has a DEBUG user interface that takes the form of alive text overlay in the top corner of the map. The overlay shows thefollowing data: (1) Number of tiles pending (Pending:#); (2) Number oftiles downloaded (D/L:#) cumulative; (3) Number of tiles loaded from thecache (Cache loads:#); (4) Number of tiles in the cache (Cache size:#);Number of tiles discarded by cache (Discards:#); and (5) Zoom level ofthe current screen (Z:#).

The user is not able to pan North of the North Pole (no wrap around tothe South Pole), nor able to pan West of −180 or East of +180 degreeslongitude. Map wraps in the horizontal direction.

The client expects to be able to request and receive any tile from theserver. If the server returns an error, the client performs three (3)retries before leaving the tile background image in place and moving on.Map is centered at the last highlighted pin (user pin, gps location, ora POI/incident pin) (i.e last pin, may be user pin, gps location disc,or a POI/incident pin that shown with a detail balloon) when “CenterMap” menu item is selected.

The map displays the buttons “traffic”, “zoom out”, “zoom in” and“locate me” on the screen. The zoom buttons are grayed out when the usercannot zoom in or out any further. The user is enabled to double clickon a location. Doing so zooms in one level using the clicked location asthe new center of the map. If a particular platform does not support a“double-click” gesture, then this is manually implemented by measuringthe time and distance between the clicks. Regarding the screen size of adevice, the number of possible buttons shown on the screen may differ.Buttons that are to be omitted on certain touch screen devices will havetheir functionality duplicated in the Menu. If functionality is presenton a button, it is not repeated in the menu, as the menu is preferred tobe as short as possible.

Shortcut keys are used to let the user interact with the map. Availableshortcuts are shown as a legend on the map, which is displayed oninitial map launch and hides with the first user interaction within theapp. “Show Legend” in menu displays legend on the map screen. The legendis hidden with the next user interaction within the app. Legend showsall shortcuts regardless of the map mode. The shortcut key press isignored by the application when the key has no valid function (e.g.pressing zoom in button at the highest zoom level.)

The user is enabled to perform general POI searches in AtlasBook v5. Theresults of these searches are displayed on the Tile Map. Clicking on themap menu entry from a UI Flow screen 3.2 displays a map showing entriesfrom the results list. If present, a Premium POI is also displayed onthe map.

POIs are represented by color pins. Different colored pins depictnormal, premium, enhanced and user POIs. For example, a purple pin isused to show Regular/Custom POIs; an orange pin to show Premium POIs;and a light green pin to show Enhanced POIs.

The map “zooms-to-all” to show all POIs on the map. A dev tool isprovided to allow experimentation between showing POI at a default zoomlevel vs. showing POI at “zoom-to-all.” With the Zoom-to-all function,all POI results listed or returned by the server are shown on the map,the premium POI is shows on the map, “my location” does not have to bevisible, and the balloon of the first POI is visible. The zoomlevel/position may be adjusted as required to make sure the balloondoesn't overlap the side or header.

The currently selected POI in the list view is shown a balloon showinginformation about the POI when map is selected from the list view ordetail view. The map also shows the other 9 (10 when there is a premiumPOI result) POI results in the visible list. If the next/previous POI isselected and the POI is outside the visible area (e.g. after the userpaned or zoomed in) then the map centers on the POI showing the balloon.If the next/previous POI is selected and the POI is on the map butshowing the balloon would result in the balloon being partially outsidethe map, then the map pans so that the balloon is visible. The exactamount of padding depends on the screen size, i.e. the percentage of thescreen filled by the balloon may be reviewed and adjusted on aper-device basis, For initial implementation, the amount of padding is 3mm or greater from any edge. Balloons are drawn under the screen buttonsshould an overlap exist (they are part of the map layer and do not coverany other element or extend outside the map). Clicking the back/forwardscreen arrows moves the balloon to/from the next/previous POI. Clickingthe back/forward screen arrows cycles through the POIs in the same orderas the POIs in the list view. If the balloon for the last POI is shownand the forward button is pressed, then the app downloads the next setof POIs. The download of new POI blocks the map control. A progress baris shown on top of the map while the download is in progress. The userhas the option of cancelling the download using a device-dependent“Back”, “Cancel” or “CLR” key. Once the download is complete, the map isupdated with the new POIs. The old POIs are removed from the map andonly the new set of POIs are shown. The map “zooms-to-all” after thedownload to show all the new POIs. The first POI in the list is shownwith its balloon visible. If the map control shows the next slice ofPOIs, then the back button is not disabled if he/she views the first POIof this slice. If the user hits the back screen arrow button, then theprevious set of POI results are shown. A blocking progress bar is notpresented if the previous results are cached. “Clear Pins” menu itemclears all the pins on the map. Selecting “List” menu item (or “List”soft-key) shows the list of the POI search results. Cycling through pinsdoes not bring focus to any existing Traffic Incidents. When the userstarts a search, the highlighted icon (blue disc, pin or incident etcwhich has the bubble) is in the search center. If no icon ishighlighted, the center of the map is used as the search center. Mapfirst reverse geocodes the map center and then starts the find module(aka find screen is shown). This address is shown on the find screens.When the user clicks back from any search related screen (a list view ora detail screen for POI, movies or events search), the search moduleupdates the map with the latest result list. In most of the cases, POIresults returned by the server include at most 10 (+1 premium) at atime, hence there are only 10(+1) pins at a time on the map. However, insome cases such as a search for events where the server may return morethan 10 results at a time, all POI results (more than 10) are shown onthe map via pins. Pins on the map always have the same number of entriesas the list, and vice versa.

With respect to touch-specific POI functionality, back/forward buttonsare shown in a device-specific location. Clicking the back/forwardarrows moves the balloon to/from the next/previous POI. If the balloonfor the first POI is shown and there is no previous POI results list,then the back button is shown disabled. If the balloon for the last POIis shown and there is no next POI results list, then the forward buttonis shown disabled. Clicking on a pin displays the balloon for that pinindependent from the back/forward buttons. This presents the device tothe user at a different point in the list should they now view the POIin list view. Any click outside a balloon and outside a pin hides theballoon. Clicking on a balloon displays the results detail screen. Ifpins are sufficiently overlapped to be considered co-located, thenclicking on the top pin cycles through all balloons of the overlappingpins. If the balloon of the last pin is shown, then it restarts thecycle.

With respect to non-touch-specific POI functionality, shortcut keys areused for non-touch devices. If the balloon for the first POI is shownand there is no previous POI results list, then clicking on 1 has noresponse. If the balloon for the last POI is shown and the search isexhausted, then the shortcut key has no response. When the user eitherclicks on D-pad so that the map is panned, or picks ID Mode from thesidebar menu, the balloon is hidden. The user may see the balloon of aPOI again, when they either click on 1 or 3. Pressing 1 shows theprevious POI from the last shown POI, and pressing 3 shows the next POIafter the last shown POI. When the user presses the select-key while aballoon is shown on the map screen, the POI detail screen is displayed.

The user can run an identification query on any arbitrary location onthe map. A Reverse Geocode is used to convert any latitude/longitudeinto the most detailed address available for that point, and the resultis then displayed on the screen using drop-pins (ID Mode).

In particular, the balloon is shown after dropping a pin. An indicationis provided to the user that reverse geocoding is in progressimmediately after dropping a pin. The balloon shows immediately with thetext string “ . . . ” (ellipsis), which is replaced by reverse geocoderesult as soon as it is available. The latitude/longitude isreverse-geocoded in the background. Once the reverse-geocoded result isreceived, the balloon automatically updates the displayed information.Only one user pin is shown at any time. Dropping a new pin removes anyold user pin. Toggling between Results Detail and map does not removethe user pin. Panning and zooming do not remove the user pin. Startingthe Follow me routine does not remove a previous POI search result ofuser-dropped pins. Selecting “Clear pins” from the menu removes the userpin. A blue pin is used to display a user pin.

A touch and hold action drops a user pin on that location, and shows theballoon.

Regarding non-touch specific drop-pin functionality, the ID Mode is usedto reverse geocode any point on the map screen. The user is able toselect ID Mode via the sidebar menu. The ID cursor is always displayedin the center, and the map slides left/right/up or down when the userpresses any arrow key or moves the trackball. When the user eitherclicks on the trackball or presses on “select”, reverse geocoding ofthat point is started in the background. The map stays on ID mode untilthe user changes the mode of the map via the menu options, or pressesany shortcut keys other than Zoom In and Zoom Out shortcut keys and Traytoggle keys. When the user starts a search by using the tray, ID mode iscancelled. The user pin is not removed when ID mode is ended.

Additional searches can be toggled on the map at any time with the useof the tray menu that appears on one edge of the map. These searches canbe customized. The results are displayed on the map when activated. Themap displays a tray handle on the left side. The tray handle has twostates: An arrow pointing to the right if it is closed, and an arrowpointing to the left if the tray is open.

The tray displays exactly 4 icons, representing 4 shortcuts for POIsearches. The icons and the searches they represent are changeablethrough the preferences. Selection of “Places Tray” from the sidebarmenu calls up the preference page to allow you to select differentshortcuts. The tray does not display any text underneath the tray icons.Performance of a tray search behaves as a regular POI search andzooms-to-all except that there is no need to reverse geocode the centerof map when it is used as the search center. The first tray search doesa zoom-to-all. “next 10” is at the same zoom level with a focus on the11th POI, and need not show all POI. “prev 10” from this screen does notchange the zoom level either. The icons may be same if the user picksthem to be. For the purpose of feature discovery, the initial tray stateis open at the first entry to map after application launch. The traycloses automatically after a system-configurable number of seconds(default is 3 s) only at the first entry to map after applicationlaunch.

Regarding touch specific tray functionality, clicking on the handletoggles the current tray state (open it if it is closed; close it if itis open). Clicking on the map or clicking any button closes the tray (ifit is open), and clicking on a tray icon also closes the tray. Clickingon a tray icon performs the appropriate POI search and shows a blockingprogress bar on the map. The user is able to cancel a search.

Regarding non-touch specific tray functionality, pressing the shortcutkey for tray open/close toggles the current tray state (open it if it isclosed; close it if it is open). When the user changes the mode of themap via the menu options, or presses any shortcut keys, the tray closes.Selection of a tray icon also closes the tray. The user is enabled tomove through tray icons via arrow keys or a track ball. The currentlyselected tray icon is highlighted. A tray icon is selected via the“select” key or by clicking on the trackball. Selection of a tray iconperforms the appropriate POI search and shows a progress bar on the map.The user is enabled to cancel a search.

Balloons are general pop-ups that appear on the map to label any objecton the map which has focus. Its contents and actions vary on the objectit identifies. The balloon has a minimum and maximum width. If themaximum width is exceeded, the ellipsis ( . . . ) is shown. The balloondisplays one line only. The balloon has rounded corners, a shadow and anarrow behind the text. The balloon displays the name if available. Ifthe name is not available then the balloon displays the street and city.If the street is not available only the city is displayed. Only oneballoon is shown at any time.

Clicking on the balloon brings up the location detail screen for theselected pin. When a balloon is displayed on the map, pressing the“select” key or clicking on the trackball brings up the location detailscreen for the selected pin.

Initial States—Pan/Zoom Mode

The preferred initial values and states for the map when a map is firstlaunched in Pan/Zoom Mode are as follows; default map mode is Pan mode;Minimum zoom level is 2, Maximum zoom level is 18; and the Minimum zoomlevel that traffic is available is 8. More details are shown on the mapas the zoom level increases.

Default start-up zoom levels are as follows: Address=16 (used whenshowing map of full postal address, e.g. 6 Liberty, Aliso Viejo,Calif.); City=10 (e.g. Aliso Viejo, Calif.); State=8 (e.g. CA); andPostal=12 (e.g. 92656).

The user is enabled to move the map via arrow keys; hold and drag; andswipe. Shortcut keys are made available on a per-device basis.

FIG. 71 shows exemplary zoom levels, in accordance with the principlesof the present invention.

The map has a Follow Me Mode similar to AtlasBook v4 which tracks theuser's GPS position and follows it by re-centering until the user endsthe tracking session, either implicitly or explicitly. Follow me mode isselected via a sidebar menu. The user location is always shown at thecenter, and the map under the user avatar slides. The user avatar isused to show the user's position and heading on the map. When the user'sspeed is below a threshold (i.e. no valid heading), a circle with across on it is displayed to represent the user's location. This iconrotates by 45 degrees with each new GPS fix. The speed threshold forheading is device-dependent and can be set in the fileset. The defaultvalue is 5.5 m/s (12.3 mph). The Follow Me remains active when the userselects: zoom in/out; or show traffic. The panning (Pan Mode), and thedropping a pin (ID Mode) is disabled when in Follow Me mode.

In the disclosed embodiments the maps do not handle Follow Me Mode andPOI Search functionality simultaneously. Clicking on a tray icon toperform a new POI search deactivates the Follow Me mode. GPS trackingalso stops when this happens. Activating Follow Me Mode does not affectany POI search that was previously executed. Pins shall remain present.Pressing a shortcut to cycle pins deactivate Follow Me Mode. Clicking ona pin from a previous search shows the balloon. The map does notre-center due to balloons which don't fit the screen. Clicking on theballoon shows the detail screen and deactivates Follow Me mode.Activation of the Follow Me mode does not change the zoom level.

Clicking on a Locate-Me/Where-Am-I button (if it is shown) has no effectin Follow Me mode. The where-am-I menu entry is disabled (or removed)from the menu when in Follow Me mode.

The map has a Where-Am-I Mode which gets the user's GPS position anddisplays it in the center of the map at an appropriate zoom level topresent the user with their immediate whereabouts. The user's currentlocation is shown with a blue disc on the map. The map is initiallycentered on the user's location. A balloon is used to show the detailsof the user's current location.

Current location is not updated automatically. Rather, the user musteither click on the “Locate Me” button (for non-touch) or select the“Where

Am I?” menu item to refresh their location.

The map has a general Traffic Overlay functionality which can be toggledat any time, comprising a tile overlay and a set of Traffic IncidentPOIs. The map has a traffic mode which can be either on or off. Togglingthe traffic mode is different between touch and non-touch devices. Themap displays a traffic overlay if the traffic mode is on. The text “Zoomin for traffic” is displayed if the traffic mode is on and the zoomlevel is above a set zoom level. The text “No traffic informationavailable” is displayed if the traffic mode is on and the zoom level isbelow the set zoom level, but there is no traffic information availablefor this region. Traffic information is displayed as overlaid tiles fromthe server. The overlaid traffic tiles are displayed asynchronously assoon as they become available.

Regarding touch traffic overlay functionality, clicking on the trafficbutton toggles the traffic mode. The traffic button indicates thetraffic mode (pressed/un-pressed button display).

Regarding non-touch traffic overlay functionality, a “Show/Hide Traffic”menu item is used to turn on/off traffic on the map.

The map has a general Traffic Overlay which can be toggled at any time,comprising a tile overlay and a set of Traffic Incident POIs.

When the user turns on the traffic feature, traffic incidents search isstarted in the background.

A traffic incident search may be performed in a bounding box centered atthe map center, and the dimension of the bounding box is larger than thearea covered by the visible map on the screen. A new search is startedwhen the user pans out of the bounding box. There are three (3)different traffic icon levels to indicate severity: Yellow(Informational/Minor), Orange (Major), and Red (Severe). When thetraffic feature is enabled, there is a menu item that shows a list ofcurrently-visible incidents. The list only contains currently visibletraffic incidents. Selection of a “Traffic Incidents” menu item showsthe list of visible traffic incidents on the current screen. Onlycurrently visible traffic incidents are shown so the list depends on themap center and zoom level.

Traffic incidents are clickable and show a balloon for it. The balloonis clickable and shows a detail screen for that traffic incident. Thecurrently selected incident in the list view shows a balloon showinginformation about the incident. Balloons are drawn under the screenbuttons should an overlap exist (they are part of the map layer andpreferably do not cover any other element or extend outside the map).There are no forward/back shortcut keys to iterate through trafficincidents on the map screen.

Traffic incidents are reachable only through “Traffic incidents” menuitem. There is no shortcut key to see the detail of the incidentsthrough the map screen.

The raster map is a user interface (UI) element. A Trip Summary screen,Detour screen and pedestrian navigation uses raster map as part of thescreen. The map features may or may not be available in these screens.

A trip summary screen is included. The Map is not intractable with theuser except zooming in/out and panning. Only zoom in/out shortcutbuttons are shown for touch devices. A show legend on map option isavailable in menu options for non-touch devices. Legend only shows zoomin/out shortcut keys for non-touch devices. Route layer is shown. Routecolor is set by the navigation module. User position is shown andupdated with GPS fixes sent by the navigation module to the mapcomponent. Traffic layer is available. The user toggles the state oftraffic layer through menu options. Traffic incidents are notselectable. The traffic incidents list is available through menuoptions.

A detour screen is provided. The Map is not intractable with the userexcept zooming in/out and panning. Only zoom in/out shortcut buttons areshown for touch devices. A show legend on map option is available inmenu options for non-touch devices. Legend only shows zoom in/outshortcut keys for non-touch devices.

Route layer is shown. Route colors (current and detour) are set by thenavigation module. Traffic layer is available. The user toggles thestate of traffic layer through menu options. Traffic incidents are notselectable. Traffic incidents list is available through menu options.Detour route is selected through menu options for non-touch devices.

Pedestrian navigation is provided. The Map is not intractable with theuser except zooming. The route layer is shown, and the route color isset by the navigation module. User position is shown and updated withGPS fixes sent by the navigation module to the map component. Breadcrumbs are shown to indicate the last 10 positions of the user. POIicons are shown along the route. Tray and shortcut buttons aren't shownexcept for zoom buttons,

Map tile expectations were derived by taking the peak number of mapqueries we see today on our largest customer deployment, multiplyingthat by average number of tiles per screen, then multiplying that byfour as a result of extra usage from end users due to the improvedfeature. Testing of these requirements is performed using well knownHTTP load test tools, such as Seige. The input data for load testing isderived from actual map queries taken from production. The queries spanat least 1 week of usage.

For the requirements below, a load test that successfully supports peakload is defined as meeting all of the following requirements: Runs forat least 1 hour; Uses URLs based on real world queries captured fromproduction; URLs cover all possible device specific combinations (thatis, it tests all tile sizes, dpi values, and regions); URLs have aregional distribution based on actual subscribers (that is, 99.99 of thequeries will be based in NA); URLs used cover at least 1 week of realworld data; Returns proper images for at least 99.999% of the requests;Processes 99% of tile images (3 standard deviations) within 333 ms; andAll tile queries are performed simultaneously.

A Map Tile Cluster supports, at minimum, a peak load of 1553transactions per second for map tiles. A Map Tile Cluster supports, atminimum, a peak load of 469 transactions per second for traffic tiles. AMap Tile Cluster supports, at minimum, a peak load of 777 transactionsper second for route overlay tiles. A Map Tile Cluster supports, atminimum, the peak loads for map tiles, traffic tiles, and route tilessimultaneously, for a grand total of 2799 (1553+469+777) transactionsper second.

A Map Tile Cluster capacity increases by adding more instances of anygiven component. Thus, cache capacity may be increased by adding anothercache; DTS capacity may be increased by adding another DTS, etc.

QA logging records are used to record tile requests and tile receipts.

The following log files are kept on the tile server (Nginx):“error.log”, which logs any information about errors encountered by theserver; and “access.log”, which logs access URLs requested by theclient, and if or not the requests succeeded.

It is important that client maps redraw at a usable speed. On platformswhere this is possible, threading is used to allow the cache to loadwith minimal impact to the drawing. Due to the large variety of deviceperformance expectations, different pass/fail thresholds are used forthe various metrics. Exemplary pass/fail thresholds include“CLIENT-METRIC-1”, which is an average time to show the first tile frommap request; and “CLIENT-METRIC-2”, which is an average time to fillscreen with tiles from map request.

Server performance is measured through the use of an HTTP load testtool. Cached and non-cached tests are performed.

Tile download bandwidth on the network is determined per client in termsof the number of concurrent downloads. All devices support tile maps.The Map Tile Server supports the “en-us” locale, and preferably does notsupport any locale settings other than “en-us”. Tiles are localizedbased on the Locale setting, controlled by the tile retrieval URL. Thelocalization applies to the label text seen on every tile.

A Map Tile Server system comprises 3 services: Cache (Varnish), Webserver (DTS), and Map Renderer (DDS). While all 3 services can run on asingle box, it is strongly suggested that they run on a 3-box cluster: a64-bit box for Varnish Cache, a 32-bit box for DTS Web Server, and a32-bit box for DDS.

As for route tiles, information within a route tile request is specificto the NB Server system that generated the route. Therefore, a separateroute tile server is required for every NB Server system.

Traffic tiles require traffic flow information. For the North Americanregion, this is provided by NAVTEQ's Realtime Traffic Feed. For theEuropean Union region, traffic information is provided by ARC.

The map data is the same as for all of ABv5: NAVTEQ 2009.Q2 UTF-8Discover Cities.

FIG. 72 shows an exemplary Tile Map architecture, in accordance with theprinciples of the present invention.

In particular, as shown in FIG. 72, the user-accessible functions listedin section Error! Reference source not found. are provided by the AppLayer. The platform-specific Map Control user interface is shown in thecenter of the figure, and the platform-independent external lower-levelAPIs are shown at the bottom of FIG. 72.

As shown in FIG. 73, the tile coordinate system divides the map of theworld into 2^(z) tiles where, z is zoom level. So for zoom level ‘0’there is one map tile with ‘entire’ world in it. For zoom level ‘1’,there are four tiles as shown in the figure below.

As shown in the figure above, the indexing starts from the top leftcorner (0,0) of the tile system. The indexing scheme used by theexemplary embodiments is the same as that used by Google map tiles.

The scale (meters/pixels) of a particular map tile at a given zoom levelis given by the following equation.

$\omega = \frac{2\pi \; r_{e}\mspace{11mu} \cos \mspace{11mu} \phi_{Y}}{2^{z}}$

Where ‘r’ is the radius of the earth (6378137 meters), φ_(Y) is thelatitude of the centre of the tile and ‘z’ the zoom level. From theabove equation, the scale for a particular tile is calculated asfollows;

${Scale} = \frac{\omega}{tileSize}$

Different map tile sizes are supported. A reference map tile serves thepurpose of comparing the scale of the map tiles for different map tilesizes. The tile size ‘256×256’ has been chosen as the reference map tilesize. However, other tile sizes are envisioned within the principles ofthe invention (assuming that all map tiles have the same width andheight), e.g., the NIM DTS supports map tiles of sizes 64×64, 128×128and 256×256.

The concept of a ‘meta tile’ is used to speed up map tile creation atthe server side. Though this is hidden from the client, the ‘scale’ usedat each zoom level varies depending on whether or not meta tiles areused. A meta tile is a ‘larger’ tile created to avoid hitting the DDS(Map Server) on a per request basis. Map creation by DDS can be a verytime consuming process, depending on the region from where the maps arerequested. For example creating map tiles for the European region isconsiderably slower than (×1000) creating maps for the ‘US’ region.Therefore, when the client requests a tile, a meta tile is basicallycreated and ‘cuts’ the appropriate region from the meta tile. This metatile is cached to avoid DDS access for the tiles falling under the metatile.

Meta tiles are turned on/off on per zoom level. When using meta tiles,the ‘new’ x, y coordinates and zoom level and tile sizes are calculatedas follows:

X=x/m

Y=y/m

Z=z−(m/2)

Tile Size=tile size*m

where ‘m’ is the meta tile factor. Meta tile factors have the followingvalues 2, 4, etc., though a meta tile factor of ‘2’ has been preferred.

When creating a meta tile, one zoom level down is used (i.e., z to z−1)to create the meta tile. This process is show in the example of FIG. 74,which shows a map tile for z=9, x=88, y=204, size=256 (reference tile).

FIG. 75 shows Metatile enabled, x=88, y=204, z=8, size=256, with aregion 290 to be cut from this meta tile to satisfy the request z=9,x=88, y=204, in accordance with the principles of the present invention.

In addition to the DTS external vendors or services may be used forfetching map tiles either as a backup or for displaying different kindsof maps.

The possible ‘types’ of maps supported include basic maps, satellitemaps, hybrid maps, and terrain maps. Basic map types may be obtainedfrom DTS, Google Maps T™, Microsoft Virtual Earth™.

The different map sources listed above can use different mapprojections. The client module that requests the tile must perform thenecessary conversions between different coordinate systems, before itmakes a request for the map tile.

Exemplary call flows and call sequences in the implementation of thetiled maps will now be described.

FIG. 76 shows an exemplary call flow sequence to obtain the map from thetiled maps server.

In particular, interactions are shown in FIG. 76 between the clientplatform layer and the server side components, such as servlets, thedynamic tile server, and the drill down server. The call depicts theretrieval of a map tile from the NIM DTS.

As shown in FIG. 76, call flow steps to obtain map tiles are as follows:

In step 1, the UI Widget requests a map tile from the Advance Tilemanager (Advanced Tile Manager (ATM)). This is usually in response to anaction taken by the user.

In step 2, the Advanced Tile Manager (ATM) module requests the map tilefrom the cache maintained at the client side.

In step 3, a check is performed to determine if the requested tile is inthe caches (RAM cache and DB cache).

In step 4, if the requested map tile is present in the cache, the tileis returned to the Advanced Tile Manager (ATM) module.

In step 5, the Advanced Tile Manager (ATM) module returns the map tileto the UI widget which then draws the map tile on the display.

In step 6, if the map tile is not present in the caches maintained atthe client side . . . .

In step 7, the map tile is requested from the data source module.

In step 8, the data source module opens a TCS connection and connects tothe NUM mux.

In step 9, the mux routes the query to the appropriate servlet.

In step 10, the data source sends the query to retrieve the list of mapsources.

In step 11, the servlet returns the list of map sources.

In step 12, the data source gets information about the map sources andsends a request to the dynamic tile server, requesting the map tile.

In step 13, the cache server (which is part of the dynamic tile server)checks if the requested tile is already cached in the server.

In step 14, if the requested tile is not present in the cache server,the cache server routes the request to the upstream server.

In step 15, the upstream server (Nginx) requests the meta-tilecorresponding to the requested tile from the DDS.

In step 16, the DDS creates the image and returns the image to Nginx.

In step 17, the Nginx tile cutter module cuts the required tile from themeta-tile returned by DDS.

In step 18, the tile cutter returns the tile to the cache server.

In step 19, the cache server caches the tile.

In step 20, the tile is returned to the client (data source module).

In step 21, the data source module returns the tile to the map tilecache.

In step 22, the map tile cache stores the newly fetched tile in thecache

In step 23, the tile is returned to the Advanced Tile Manager (ATM)module.

In step 24, the Advanced Tile Manager (ATM) module returns the module tothe UI.

In step 25, the UI Widget draws the image on the UI.

The following is a sequence diagram depicts the sequence of operationsinvolved in retrieving and displaying overlay (traffic) tiles on theclient UI. The overlay tiles are created by the server upon the clientrequest.

In particular, in a step 1, the user enters a raster map screen from anypoint in the application. (i.e. Maps->Where am I?, Maps->Follow me Map)

In step 2, the map is drawn as quickly as possible.

In step 3, the user's GPS position is drawn on top of the map whenprovided.

In step 4, the user controls the cursor using the arrow keys to operatethe panning/selection on the map for non-touch-screen devices.

The user may continue to interact with the map if they want while themap tiles are downloaded (i.e., there is no lockout of the UI flowduring the download.)

In an alternate scenario, if there are missing tiles in the ClientApp,placeholder images are drawn instead of the missing map tiles. Then themissing map tiles are redrawn when appropriate after they aredownloaded.

In another alternate scenario, the user pans to any edge of the map.Then the user may experience some parts of the map screen in lowerresolution. This happens when there are missing tiles. These areas arecovered by tiles from a lower zoom level until they are downloaded,hence will look blurry for a while.

The route highlight and the traffic information are sent as overlaytiles separately instead of a sent together with map on the same tile.Relevant devices are the ‘User’ (the actual device using theapplication); the ‘ClientApp’ (the client application); and NIMServer(the provider's server). To achieve this, first the user enters a rastermap screen from any point in the application (e.g., Navigation->Map ofRoute). Then the user asks for traffic information. Lastly, the trafficinformation is drawn on top of the current map.

In one alternative example, the user pans the map. Traffic incidents onthe new map are then shown on the map, if traffic incidents are enabledfor the previous map.

In another alternate embodiment, the route is shown on top of the mapwhen in “map of route” mode, or any screen that route information isavailable on. In yet another alternate embodiment, placemarks (POIs) areshown on the map when provided. “Ballons” are used to show the captionsor details for that POI. Lastly, when the user pans the map, a newsearch for new POIs is not performed automatically. Only the previousexisting POIs are shown.

In still one more alternative example, the user selects disablement ofthe traffic information, in which case the traffic information isinstantly erased from the map.

To perform zoom, the ‘User’, ‘ClientApp’, and ‘NIMServer’ elements areinvolved, Described as a process, the user first enters a raster mapscreen from any point in the application (e.g., Maps->Where am I?,Maps->Follow me Map). The user then zooms in via any available zoom-inoption. The zoomed-in map screen is drawn (possibly at a lowerresolution in an initial drawing).

In an alternative embodiment, the user zooms out via any available zoomoption. The zoomed-out map screen is drawn quickly, initially at a lowerresolution, but eventually getting sharper.

When the user clicks on a POI, a balloon is shown, using the scaled downor up version of previous map tiles until the map tiles for the currentmap are downloaded.

The user is presented with friendly shortcuts to zoom in or out and panquickly for touch screen phones. In particular, the user enters a rastermap screen from any point in the application (e.g., Maps->Where am I?,Maps->Follow me Map). The user then enters an input through an arrow keyor a trackball or any other appropriate directional key. The map screenor the cursor is panned in the direction of the input.

For touch screen devices, the user double taps the screen, and the mapscreen zooms in one level. In an alternative embodiment, the user DRAGsthe screen by either finger or stylus. Newly-revealed tiles aredownloaded when the user releases the finger/stylus. In yet anotherscenario, the user FLICKs the screen by dragging with sufficientvelocity. In response, the map pans on its own in the direction of theflick until it decelerates to a stop. Newly-revealed tiles aredownloaded when the map stops moving.

For multi-touch input screen devices, in an exemplary case the usertwo-finger double taps the screen, and the map screen zooms out onelevel. In an alternative embodiment the user does a pinch-in gesture onthe screen. The map screen then zooms out based on the pinch. The centerof the map then moves along with the center of the pinch, and the mapsets its new zoom level upon completion of the gesture.

In still another case scenario, the user does a pinch-out gesture on thescreen. In response, the map screen zooms in based on the pinch. Thecenter of the map moves along with the center of the pinch. The map setsits new zoom level upon completion of the gesture.

Auto pan of the map, i.e., movement of the center of the map changedappropriately by user actions, is now described.

In particular, the user first enters a raster map screen from any pointsin the application. (i.e. Maps->Where am I?, Maps->Follow me Map). Theuser enables POIs on the map. The user clicks on a POI at the any edgeof the map. The center of the map is then set to the location of theselected POI. Note that the selected POI need not necessarily be set tothe center, but rather to somewhere that feels best for the userexperience.

The user can change the tile modes for the raster maps. Availableoptions include map, bird's eye, satellite, etc. To do this, the user isenabled to enter a raster map screen from any point in the application(e.g., Maps->Where am I?, Maps->Follow me Map). The user then changesthe tile map mode from maps to satellite, and then the satellite versionof the current map is displayed.

These options will only be valid when the ClientApp has a URL to aserver capable of different tiles. The ClientApp has built in flags tosupport this use-case when required.

The map data is updated automatically with every draw if there are anychanges to layers, etc. that have been made since the last draw. TOaccomplish this, the user is enabled to enter a raster map screen fromany point in the application (e.g., Maps->Where am I?, Maps->Follow meMap). The map data cached in the ClientApp is updated if necessary. Thelatest version of the map is then drawn on the screen.

Maps are preloaded as much as possible to provide faster rendering ofmap tiles. The user enters a raster map screen from any point in theapplication. The user flicks on the map, and the map moves viaanimation. As a variation of this scenario, a popup enters the screenwhile animation is in progress, causing the animation to stop. The mapis moved to its final location instantly without animation.

The MAP Tile UI component draws tiles in their appropriate positions onthe screen, or draws placeholder images when tiles are not yet present.Rout overlays are drawn over map, as are traffic overlays. PLacemarkicons are drawn on top of the map when provided. ‘Balloons’ are drawnfor placement icons to show captions or details for that placemark. Theuser's GPS position is drawn on top of the map when provided. Uponzooming in or out, the Map Tile UI component draws the previous zoom'stiles scaled to cover the area until the new tiles are loaded. Whenpanning, the Map Tile UI component attempts to cover any areas stillneeding to be downloaded with tiles from a lower zoom level until thesenew tiles are downloaded. A cursor is provided to operate thepanning/selection on the map for non-touch-screen devices, controllableusing arrow keys. The Map Tile UI component provides controls forbuttons to change between different base/overlay tiles, wheneverpresent. Upon being notified of receipt of tiles, the Map Tile UIcomponent redraws itself when appropriate.

The Map Tile UI component handles events from arrow keys, trackballs,other appropriate directional keys, etc. for panning the map and/ormoving a cursor. Drag events are handled if the map is panned with theuser's finger or stylus. Newly-revealed tiles are downloaded when theuser releases the finger/stylus. Flick events are handled if the userdrags with sufficient velocity. This causes the map to pan on its own inthe direction of the flick until it decelerates to a stop.Newly-revealed tiles are downloaded when the map stops moving.Two-finger double tap gestures on multi-touch input screens zoom out onelevel on the map.

The Map Tile UI provides an API to set the center position of the map inlat/llon, an API to change zoom level, an API for the application tochange the tile mode (e.g., between map mode, bird's eye mode, satellitemode, etc.) An API toggles the viewing of traffic data, and sets the mapviewing size. An API queries the available features of the UI component,and specifies a route overlay on the map. An API passes a list ofplacemark icons and callbacks used for user interaction with them, andredraws the map and updates it with any changes to layers, etc. thathave been made since the last draw. The tiles necessary to display thecurrent map are pre-loaded, and the available map tile types (e.g.,road, satellite, bird's eye view, etc.) are enumerated. An API selectsfrom the available map tile types, and an API enumerates the availablemap overlay types (e.g., traffic, route). An API selects from theavailable map overlay types, and an API translates between lat/llon andpixe. coordinates of the map view. An API retrieves the center of themap in lat/llon, and one obtains the bounding box of the map view inlat/llon. An API obtains the lat/llon for any map view pixel coordinate,and one obtains the map view coordinate for any lat/llon. The Map TileUI component includes an API to let the application choose whether toshow controls to allow the user to manipulate the map view. Thisincludes buttons for showing map tile types and overlay types. An APIprogrammatically manipulates the map view, and an API sets the centerpoint of the current map view to a specific latitude and longitude. ThisAPI includes an option to animate this transision, and a callbackfunction to be called when the animation is complete. An API sets thezoom level of the current map view, this API including an option toanimate this transition, and a callback function to be called when theanimation is complete. An API zooms to a specific bounding box, this APIincluding an option to animate this transition, and a callback functionto be called when the animation is complete. An API determines if ananimation is currently in progress, and an API cancels the currentanimation. An API jumps to the final position of the current animation.Another API allows the implementation of Custom Map Overlays, using aspecific set of callback functions or interfaces. One API supportsmultiple custom map overlays, and another allows a custom overlay todraw its content into the map view while allowing for multiple drawinglayers (drop shadows, main content, labels, etc.) An API allows a customoverlay to handle key events, and another API allows a custom overlay tohandle touch events.

The following are means by which the App Layer makes use of the Map TileUI component.

An API sets the center position of the map in lat/llon.

An API changes zoom level.

An API toggles the viewing of traffic data.

An API sets the map viewing size.

An API queries the available features of the UI component.

An API specifies a route overlay on the map.

An API passes a list of placemark icons and callbacks used for userinteraction with them,

An API passes a list of placemark icons and callbacks used for userinteraction with them.

An API redraws the map and update it with any changes to layers, etc.that have been made since the last draw.

An API pre-loads the tiles necessary to display the current map.

An API enumerates the available map tile types (road, satellite, bird'seye view, etc.)

An API selects from the available map tile types, and an API enumeratesthe available map overlay types (e.g., traffic, route).

An API selects from the available map overlay types.

An API translates between lat/llon and pixel coordinates of the mapview.

An API retrieves the center of the map in lat/llon.

An API obtains the bounding box of the map view in lat/llon.

An API obtains the lat/llon for any map view pixel coordinate.

An API obtains the map view coordinate for any lat/llon.

An API lets the application choose whether to show controls to allow theuser to manipulate the map view. This includes buttons for showing maptile types and overlay types.

An API programmatically manipulates the map view.

An API sets the center point of the current map view to a specificlatitude and longitude. This API includes an option to animate thistransition, and a callback function to be called when the animation iscomplete.

An API sets the zoom level of the current map view. This API includes anoption to animate this transition, and a callback function to be calledwhen the animation is complete.

An API zooms to a specific bounding box. This API includes an option toanimate this transition, and a callback function to be called when theanimation is complete.

An API determines if an animation is currently in progress.

An API cancels the current animation.

An API jumps to the final position of the current animation.

An API allows the implementation of Custom Map Overlays. This wouldnormally be accomplished by allowing the developer to implement aspecific set of callback functions or interfaces.

A Custom Overlay API supports multiple custom map overlays, and allows acustom overlay to draw its content into the map view while allowing formultiple drawing layers (drop shadows, main content, labels, etc.) TheCustom Overlay API allows a custom overlay to handle key events, and tohandle touch events.

An API notifies the application if a touch and hold operation occurs forthe application to perform a custom operation such as dropping a new pinat the lat/llon.

The Map Tile UI component resides in the NavBuilder UI component of theplatform-specific app layer. Its purpose is to retrieve tiles from theNavBuilder™ Inside (NBI) layer, draw tiles to the screen, and handleuser input events. It is implemented natively to maximize access tonative interaction controls.

The Map Tile UI component draws tiles in their appropriate positions onthe screen, or draws placeholder images when tiles are not yet present,it draws route overlays over map, and traffic overlays over map. The MapTile UI component draws placement icons on top of the map when provided,and “balloons” for placemark icons for the purpose of showing captionsor details for that placemark. The user's GPS position is drawn on topof the map when provided, and draws the previous zoom's tiles scaled tocover the area until the new tiles are loaded. When panning, the MapTile UI component attempts to cover any areas needing to be downloadedwith tiles from a lower zoom level until these new tiles are downloaded.The Map Tile UI component provides a cursor to operate thepanning/selection on the map for non-touch-screen devices, controllableusing the arrow keys. The Map Tile UI component provides controls forbuttons to change between different bases/overlay tiles, wheneverpresent.

The Map Tile UI component also handles input events. For instance, theMap Tile UI component handles events from arrow keys, trackballs, otherappropriate directional keys, etc. for panning the map and/or moving acursor. Double-tap gestures for zooming in one level on the map arehandled, as are drag events to pan the map with the user's finger orstylus. Newly revealed tiles are downloaded when the user releases thefinger/stylus. Flick events are handled if the user drags withsufficient velocity. This causes the map to pan on its own in thedirection of the flick until it decelerates to a stop. Newly-revealedtiles are downloaded when the map stops moving. Two-finger double tapgestures are handled on multi-touch input screens to zoom out one levelon the map. Pinch-in gestures are handled on multi-touch input screensto zoom out based on the pinch. The center of the map moves along withthe center of the pinch. The map sets its new zoom level upon completionof the gesture. Pinch-out gestures are handled on multi-touch inputscreens to zoom in based on the pinch. The center of the map moves alongwith the center of the pinch. The map sets its new zoom level uponcompletion of the gesture. Touch and hold gestures are handled to drop apin placemark at the relevant location for reverse-geocoding and therebyobtain an address for the pinned location.

The following are ways that the Map Tile UI component interacts with theNavBuilder™ Inside (NBI) Layer portion of Tile Maps. The Map Tile UIcomponent requests tiles by coordinate from the Advanced Tile Managerusing the universal <tx, ty, tz> coordinates, plus a priority parameterbased on the tile's position relative to the screen center. The Map TileUI component registers to be notified upon receipt of requested tiles.

The Tile Map UI component, upon notification of receipt of tiles,redraws itself when appropriate.

An Advanced Tile Manager component resides in the NavBuiIder™ Inside(NBI) component of the platform-independent layer. Its purpose is toretrieve and store tiles as requested by the UI layer, as well as tomanage the tile cache of the system and the data interaction layer. Itis agnostic of any map center or user interaction and is focused on theretrieval of tiles as prioritized by the UI layer.

The following are requirements for the interface by which the UI layerrequests tiles and sets up notification of new tiles. In particular, theAdvanced Tile Manager provides a generic Get Tile function which takesuniversal tile coordinates, a download priority, and the type of tileimage (map, bird's eye, satellite, etc.) The Advanced Tile Managerreturns the tile if found in the cache, or signals to the caller thatthe tile has been added to the download queue. The Advanced Tile Managerprovides a way to notify the UI layer that a tile previously added tothe download queue is available for drawing. The Advanced Tile Managerprovides a way to reset the priority of pending tiles so that theirpriority can be reevaluated by the UI layer. The Advanced Tile Managerprovides a way to flush pending tiles that are no longer relevant to thecurrent map state.

The Advanced Tile Manager component manages the cache as well as thedata services. The following are the required operations carried out bythe Advanced Tile Manager (ATM) that do not pertain to externalinterfaces. In addition, the Advanced Tile Manager (ATM) keeps track ofusage data, collected for the session and saved in prefs.

In particular, the Advanced Tile Manager manages a queue of pending tiledownloads ordered by priority, maintains the Data Source object, andmaintains the Map Tile Cache object. The Advanced Tile Manager uses theresult from the Data Source's Service URL query to invalidate/clear theMap Tile Cache in the event of a new tile generation. The Advanced TileManager mediates tile requests between the UI Layer, the Map Tile Cache,and the Data Source as necessary, and adds tiles to the Cache uponreceipt of them from the Data Source. The Advanced Tile Manager keepstrack of usage data for Tile Maps, comprising per-tile-type data, andstored in persistent storage for Data Source to upload later for (1)Total number of requests; (2) Number of RAM cache hits; (3) Number ofDatabase Cache hits; and (4) Tiles retrieved from the server.

The Map Tile Cache component is an NavBuilder™ Inside (NBI) component ofthe platform-independent layer. It has two levels of caching: a RAMcache and a database cache. The multi-level design is intended tooptimize the speed in which tiles are fetched (RAM portion) while havinga means of persistent storage for future sessions (database cache).

The RAM cache is a temporary cache for tiles that are the most relevantfor drawing to the screen to avoid pauses caused by loading tiles fromthe database cache. Since the cache has no concept of screen position,tile relevance is tracked by the most recent request that was made forthe tiles. The RAM Cache is a temporary storage for recently-fetchedtiles and remains active until the app is exited. The RAM Cache has acapacity that is proportional to the number of tiles that could berealistically fetched at once to prevent thrashing. The RAM Cache, whenat capacity, drops tiles in least recently used (LRU) order for storagein the DB cache. The RAM Cache serves as storage for tiles both as theyare downloaded from the server and when they are recalled from thelower-level cache.

The database cache is a persistent means of tile storage and holds mostcommonly-used tiles to avoid accessing the network, One tile databasesaves tiles from all zoom levels. A combination of “least-often-used”and “least-recently-used” (least often used (LOU) and least recentlyused (LRU) attributes are used to discard tiles from this cache when ithas reached its capacity. The Database Cache has persistent storage onthe device with a device-configurable maximum capacity, and keeps trackof how often tiles are accessed to determine which tiles to throw outwhen full. The Database Cache both stores and retrieves tiles fastenough to be performed synchronously.

All multi-level caching operations are handled within the Map Tilecache, leaving a very simple get/add/clear interface. The Map Tile Cacheprovides a means to Get a tile, which first looks in the RAM cache andthen looks in the database. If there is a “hit” in the database, it isloaded into the RAM cache. The Map Tile Cache provides a means to Addnew tiles to the cache when they are downloaded. The Map Tile Cacheprovides a means to Clear the database and RAM caches when a new tilegeneration is detected, or for other purposes such as theun-installation of the app or a Master Clear,

The Data Source component is an NavBuilder™ Inside (NBI) component ofthe platform-independent layer which is responsible for the interactionwith both the NIM Service URL server and the HTTP tile server. DataSource is also responsible for tracking user analytics, which tracksinformation for each tile request and download.

One duty of the Data Source component is to obtain the Service URL usedto download tiles over a HTTP connection. Upon initialization, the DataSouce makes a request to the NIM Service URL server to obtain the formatfor the requests and tile generation for the pre-designated tile server.The Data Source considers this Service URL valid for the duration of theapplication session. As part of the request, Data Source also uploadsusage data collected from the previous session. The Service URL returnedby the server has a schema flexible enough to provide a template for anyprovider's tile URL.

If the system does not have a needed map tile, the Advanced Tile Manager(ATM) requests a tile from Data Source. It is the duty of Data Source todo the conversion functions necessary to form an HTTP request to obtainmap tiles. The Data Source has the ability to create HTTP file requestsusing the template provided by the Service URL and the universal tilerequest parameters as provided by the higher layers.

Data Source provides a means for the Advanced Tile Manager (ATM) to maketile requests in universal tile <tx, ty, tz> coordinates, along with asupplied map type. Note that different map sources might supportdifferent map projections and the client module might need to convertfrom one coordinate system to another. The Data Source provides a meansto cancel all pending tile downloads, and a notification system toreturn tiles asynchronously after completing a tile download request.

Upon launch of Tile Map data services, the client needs to retrieve amap server URL from NIM servers. This URL is specified as a template formaking requests from that particular server. The template hasplaceholders for the ‘parameters’, which are filled in by the client,before issuing the HTTP request. This extra ‘layer’ between the clientapp and the dynamic tile server is put in place so that an administratorcan update the URL at the server side and thus point the client to a‘different’ map server, with ease.

The map server returns a value indicating the ‘generation’ of the maptiles along with other information related to a ‘map source’. Client canuse this value to invalidate the cache it maintains at the client side.The map server returns a value indicating the ‘map projection’associated with each returned map source. The map source server returnsinformation about at least 2 map sources. One primary and the other,secondary,

The URL ‘template’, returned by the map source server, has the followingparameters.

Parameter Description type type of the tile downloaded ‘map’ - base maptile. ‘traffic’ - traffic overlay tile ‘route’ - route polyline tile vversion of map tiles. $fmt image format can be any one of the following;‘png’ ‘gif’ ‘jpg’ x x coordinate of the requested map tile y ycoordinate of the requested map tile z zoom level sz size of the maptile (width shall be equal to the height) res Map resolution. This isthe DPI value for the device's screen size. Takes the format ‘X’ where Xis the DPI value. ‘96’, ‘192’ etc. <rid1> This parameter is only validfor ‘route’ overlay tiles. This is base64 encoded version of therouteid. <rc1> This parameter is only valid for ‘route’ overlay tiles.Color is specified either as RRGGBB or RRGGBBAA. <rid2> Similar to‘rid1’ parameter. This parameter was added to support route detours.<rc2> Similar to ‘rc1’ parameter. This parameter was added to supportroute detours.

The Dynamic Tile Server (DTS) is the source from where clients candownload ‘base’ map tiles using the HTTP protocol. Internally the maptiles served by the DTS are generated by the DDS and depict geographicalfeatures. The dynamic tile server provides an HTTP interface for theclients to download map tiles, and supports PNG, GIF and JPG imageformats. The dynamic tile server supports tiles of size 256×256 and128×128 and 64×64. While the dynamic tile server supports only one tilesize from a list of supported tile sizes (at this time comprising 64×64,128×128 and 256×256), support for other tile sizes are within theprinciples of the present invention. Dynamic tile server supportsgeneration of maps for both ‘low’ and ‘high’ resolution devices. DynamicTile Server supports caching of the generated tiles at the server sideto speed up the process of delivering the map tiles.

With the design of the new map tile server, the base map tile isgenerated from a dedicated tile server (DTS), which serves ‘base’ maptiles for different zoom levels. The overlay tile server has theresponsibility of serving different ‘overlay’ tiles. An overlay tilehere means an image of either the route polyline or the traffic flow,with a transparent background. The transparent background enables theclient application to ‘overlay’ the tiles as appropriate on the ‘base’map tiles.

The overlay tile server provides an HTTP interface for the client todownload a particular overlay tile, and supports two kinds of overlaytiles: traffic tiles, and route polyline tiles. The overlay tile servergenerates tile images with a transparent background, and generates theoverlay tile image for a given x,y coordinate (unit is a tile) and azoom level. The overlay the image server is delivered in the ?NG′format, and allows the client to specify the tile size. The overlay tileserver supports tile sizes (length, breadth) which are powers of 2, andsupports caching at the server side to speed up delivery of the overlayimages. The tile servers serve ‘tiles’ of different types. The tiles canbe ‘base’ map tiles, traffic tiles etc. The dynamic tile server can beaccessed through the HTTP interface to download a map tile. The HTTPclient requests a particular tile by specifying the coordinate (x, y) ofthe tile and the zoom level.

The URL format is as follows:

http://www.server.com/type!v=‘version’&loc=‘locale’&fmt=‘format’&res=‘res’&x=‘x’&y=‘y’&z=‘z’&sz=‘sie’&rid=‘route’&rc=‘color’‘$rid’ and ‘$rc’ are optional parameters and are only valid when a‘route polyline’ overlay tile is requested. For example, the HTTPrequest for downloading a traffic tile for coordinate (4, 5) at zoomlevel 3 has the following form:http://www.server.com/traffic?v=1.0&loc=enus&fmt=PNG&res=96&x=3&y=4&z=5&sz=256

Similarly, to request a ‘route’ polyline for the coordinate (4,5) atzoom level 3, displaying the route identified by route ‘xyz’ has thefollowing form:

http://www.server.com/route?v=1.0&loc=enus&fmt=PNG&res=96&x=3&y=4&z=5&sz=256&rid1=a1b2b3b4b5&rc1=FF0000

Also, to draw two routes on the overlay, the request is issued asfollows:

http://www.server.com/route?v=1.0&loc=enus&fmt=PNG&res=96&x=3&y=4&z=5&sz=256&rid1=a1b2b3b4b5&rc1=0000FF&rid2=a1b2b3b4b5&rc2=FF0000

Note: A maximum of two routes can be drawn on an overlay.

The dynamic tile server includes different hardware components such as aNginx HTTP Server and a Varnish cache server. The Dynamic Tile Server(DTS) requires a 64 bit server to implement caching, with a cache sizein excess of 2 Gb.

The TPS servlets for a tiled map support the following functions(queries):

a map tile source request (maptile-source-query) to obtain a validatedlocation for a user specified location.

a map tile source reply (maptile-source-reply) to obtain a validatedlocation for a user specified location.

Type Number Description maptile-source 1 . . . n Information about themap tile source

Maptile Source

Type Number Description internal-source 0 . . . 1 If present, the mapsource is owned by NIM. url 0 . . . 1 The tile server base URLurl-args-template 0 . . . 3 The url templates to be used for fetchingdifferent types of tiles. The ‘real’ URL shall be formed byconcatenating ‘server-url’ with the appropriate url template from thiscollection.

Attributes

Name Type Description gen string Generation of the map tiles projectionstring Map projection type. The client can use this value to determine,if it needs to convert the NIM coordinates to match the coordinatesystem used by the map source server. Supported types: ‘mercator’ Note:-This element is added to support diverse 3^(rd) party map sources. NIMmap server uses Mercator projection. But other map sources might usedifferent map projections.

URL-ARGS Template

This element specifies the URL template for a particular ‘map tile’type.

Name Type Description type string Type of the tile downloaded ‘map’ -base map tile. ‘traffic’ - traffic overlay tile ‘route’ - route polylinetile template string The template for the URL arguments. ParameterDescription $v The version (generation) of tiles $loc The locale. Ex:‘en-us’ $fmt Format can be any one of the following: ‘PNG’ ‘GIF’ ‘JPG’$x x coordinate of the requested map tile $y y coordinate of therequested map tile $z zoom level $sz size of the map tile (width shallbe equal to the height) $res map resolution The resolution is specifiedas client DPI. <$rid1> This parameter is only valid for ‘route’ overlaytiles. This is the base64 encoded representation of the ‘route id’.<$rc1> This parameter is only valid for ‘route’ overlay tiles. Color isspecified either as RGB(r, g, b) or RGB(r, b, g, a) <$rid2> Similar to‘$rid2’ <$rc2> Similar to ‘$rc2’ Note:- The second route parameter set(‘$rid2’ and ‘$rc2’) is optional, so those parameters are not present inthe exemplary template.

It may be desirable to limit the maximum number of routes that can bespecified on a route overlay, e.g., to 2 routes.

The URL element specifies the map usage data that is uploaded by theclient to a server side persistent medium.

Facebook Update

Facebook™ is an external website that aids its users with their socialnetworking needs. In accordance with the principles of the presentinvention, “NIM FB APP” is a Facebook application created forcommunicating with Facebook for each of the users. “NIM FB APP DB” is adatabase for NIM FB APP functionality.

The AB Navigator mobile client provides users with location basedservices they are interested in. This inventive Facebook update featureprovides the user with an option to update the status field of his/herFacebook (FB) account from the AB Navigator mobile client.

There are three ways to communicate with FB servers: The first method,which can be used for any platform, creates the web Facebook application“MM FB APP” for this purpose. The MM FB APP is the medium ofcommunication between AB Navigator and Facebook servers. To facilitatethis, the user adds the NIM FB APP onto their Facebook account. Uponadding the NIM FB APP to their account, Facebook would generate a useridand session key associating the NIM FB APP and the user account. Thisuserid and session key are used to directly talk to the Facebook serverfor updating the user's status.

The second method uses the FACEBOOK Connect library, provided byFacebook. This is currently only available as an Objective C librarywhich can be used for the iPhone platform. The library provides api forauthenticating the user through the mobile client, and uses the Facebookapi to update status directly from the mobile client.

The third method uses the Short Messaging System (SMS) mechanism, thoughthis method involves the costs associated with SMS, and also won't givethe complete capabilities that are obtained from the api. Because ofthese issues the third method is not preferred over the second approach.The second method provides a platform on which there is no library todirectly talk to Facebook servers, e.g., the use of the FB Connect apifor iPhone.

FIG. 77 shows an overall functional block diagram of an exemplaryplatform taking the first approach, in accordance with the principles ofthe present invention.

A goal of the Facebook status update in accordance with the principlesof the present invention is to provide the user with the ability toupdate the status field of their Facebook account with the locationbased information available on the mobile client, with minimal delay.

The client, upon first access to the Facebook status update feature,show an information popup menu instructing the user about how to proceedfor authentication. The authenticating web application provides an easyto use PIN, and obtains a password from the user to match with apre-stored PIN associated with an authorized user. This is performedwhen received from the mobile client to avoid unintended PIN matching.An SMS notification may be used if desired.

The client uses an FBConnect api (Facebook connect library) forauthentication for the given platform.

The user is able to select any location based information available forconstructing the status, and is able to view and customize the messagebefore posting it. The user is provided with an option to set a defaultprefix and suffic, which are applied for all posted messages. The userhas a choice of posting the status as a Short story or as a Full story.

The user is provided with an option to reset the password. The user isshown the PIN if it is not already attached to the client key. The useris enabled to send a SMS message with the PIN and password.

The user is provided with an option to change the prefix and suffix ofthe message at the point in time from the application preferences.

Cell ID

The CellID servlet provides a newly powered on mobile terminal (phone)with an approximate location until a GPS fix has been obtained. Thelocation is obtained by providing information about the mobile networkresources (network code, cell id etc) currently seen by the terminal toa web service, which translates these into a lat/llon point that isreturned to the terminal. The lat/llon location can then be used by thephone to initiate navigation (poi, etc) before the GPS fix process hascompleted.

The CellID is implemented as a new tps transaction which can be sentfrom a terminal to a mux. The servlet itself contacts a web service(currently navizon) to do the translation.

Network types supported in the exemplary embodiments are CDMA, GSM andWiFi.

The CellID is a GSM/CDMA A single base station within a Location AreaCode (LAC, which is a GSM definition of a collection of geographicallycontingent base stations. The CellID is implemented as a servlet, whichreceives incoming queries from the terminal. The CellID accesses anexternal web service to translate the provided network information to alatitude/longitude/radius (lat/llon/radius) triplet. The returned radiusspecifies a circle around the lat/llon point that the terminal islocated within.

Multiple network information entries may be provided by a terminal toincrease accuracy. These entries can be mixed from several differentnetwork types such as GSM, CDMA and WiFi. The web service aggregatesposition from all entries to achieve a more exact location.

FIG. 78 shows an exemplary flow of information from terminal to the webservice, and back, in accordance with the principles of the presentinvention.

The CellID preferably supports queries for CDMA, GSM and WiFi networktypes. CDMA utilizes SID, NID, CellID and signal strength networkresources; GSM utilizes MCC, MNC, LAC, CellID and signal strengthnetwork resources; and WiFi utilizes WiFi router MAC address and signalstrength.

A single CellID-query sent from the terminal supports multiple networkresource entries to increase precision of the returned answer. Resourceswithin a single entry may be of different types (such as WiFi and GSM)if necessary. In the disclosed embodiments, up to 5 resources can bespecified.

The location returned from the CellID servlet to the terminal contains aradius-of-confidence describing a circle around the lat/lon position inwhich the terminal is located.

Exemplary elements that are configurable (through the standardconfiguration system) for the CeIIID servlet include: License key (usedto authorize the servlet toward the web service); Web service host(which is the DNS name or IP address of the web server that does thetranslation); and Web server URI (which is the URI, or path within theweb server, that the service resides in.)

In addition to normal events generated by the servlet framework, aspecific event is generated for each successful transaction handled bythe CeIIID servlet. In disclosed embodiments the event contains thefollowing information:

time stamp; device ID (e.g., MDN, MSISDN); the data sent to the webservice; the returned lat/llon position; the returnedradius-of-confidence; and the method (according to the web service) thatthe device's position was obtained through.

The CellID servlet is completely dependent on the authorized web service(e.g., Navizon web service) for its operation. Requirements placed onthe servlet are constrained by functionality available from the webservice.

The CellID capacity is limited by the web service (e.g., Navizon)capacity and/or SLA.

Multiple CellID servlets are deployed to scale to more clients. Sincethe CellID does not do anything but forward requests to the web serviceand generate event records, the servlet is unlikely to become abottleneck before the web service (e.g., Navizon) reaches its limits.

Warnings are logged when one or more of the following conditions occur:The web service is unavailable; The web service did not reply with a“200 OK HTTP” response; Not all necessary TPS arguments were provided bythe terminal; and/or Provided TPS arguments were out of range orincorrectly formatted.

To limit network bandwidth usage, the communication between a singleservlet and the web service preferably does not exceed 512 bytes to theservice and 512 bytes back from the service, including HTTP headers.

The devices that use the CellID servlet are able to access informationabout network resources available to the terminal. This access isprovided through a client-side API.

As an exemplary call flow:

1. Terminal sets up data link to the mux;

2. Terminal sends CellID tps request;

3. Mux forwards request to CellID servlet;

4. CellID servlet repackages incoming TPS elements to a HTTP URL;

5. CellID servlet sends request to Navizon server;

6. CellID servlet repackages reply lat/llon/radius to a CellID tpsreply;

7. CellID servlet sends reply to mux; and

8. Mux forwards reply to the handset.

Traffic Probes

Traffic Probes is/are a new navigation application v5.0 feature tocollect near real time traffic speed information.

FIG. 79 shows an exemplary traffic probe network, in accordance with theprinciples of the present invention.

In particular, as shown in FIG. 79, accumulated traffic data is sent toa traffic server, which forwards the information to the traffic dataprovider. Ideally, the data is used to generate more accurate trafficspeed information for freeways, and may provide information for roadwayswithout dedicated speed sensors.

The system design of Traffic Probes includes modifications to theAtlasBook client, server and databases. A user accessible web site isnot necessary for the system to function properly.

During a navigation session and while viewing a Follow Me Map, theclient saves GPS fix information at set intervals and periodicallytransfers the accumulated data to the server. The server, in turn,transfers the information to the traffic data provider. All valid fixesare transmitted to the provider; no data filtering is done on the clientor server.

Traffic Probes need not be tightly integrated with navigation. That is,the current speed need not be correlated with the speed limit orexpected travel speed of the current routing segment to provide specialfunctionality. The only correlation is that the probes from a singlenavigation or “follow me” session have the same navigation session ID toindicate that they belong to the same route. The only impact theseprobes have on navigation is that there is an additional, “out-of-band,”upload to send the accumulated fix data to the server prior to the finalmaneuver announcement, reducing the chance that the application will endbefore transmitting cached data to the server.

Carriers are able to decide whether this feature is voluntary ormandatory. In either case, they are provided with the ability to requirethe user to acknowledge that their location and speed information may beanonymously sent to a third party for processing. If the feature isvoluntary, users may opt-in or opt-out of Traffic Probes at any time bymodifying preferences within the client. A carrier may also require thatthe user be allowed to review the terms of the Traffic Probes agreementwithin the client.

Traffic probes upload collected data to optimize usage of networkresources.

User participation may be compulsory or voluntary.

Data is collected during navigation and Follow Me Map sessions. The dataincludes timestamp, latitude, longitude, speed and heading information.Collected data is uploaded automatically with no perceivable impact onthe user. Data is sent to a traffic partner with no identifyinginformation, to ensure privacy. Uploaded data may be stored for a givenrelevant period of time, e.g., for at least one month. Collection andupload frequency is preferably configurable by the server. Trafficprobes do not impact user performance. Voluntary users may changeparticipation at any time.

Traffic Probes participation may be either mandatory or voluntary on aper-build basis, thus each client build has a default participation.Participation in traffic probes is configured by client build based onproduct information such as carrier and product. Mandatory participationallows a notice, in the form of a EULA, MOTD or help text displayed tothe user. Voluntary participation has a default value for eachcarrier/product combination, which is configured on the client. Theclient allows the user to change from the default participation duringFTT (first time through) processing with a “confirmation MOTD” or“Feature EULA”. The client considers the next invocation after the“Master Clear” function has been used as FTT. The client allows the userto change participation with a new option within a General Preferencesmenu. The client immediately deletes any collected data whenever theuser opts out. The server retains any uploaded probe data if the useropts out. The client does not provide a new settings option formandatory participation. The server stores the user participationsetting in the server's user database. The user participation setting issynched with the client, and may be made available to sync with acompanion web site.

With respect to configuration, a preferred default of 15 secondscollection sample rate is set (i.e., how often, preferably in seconds,to collect data.) A default of 900 seconds (15 minutes) is set for thetransmission interval (i.e., the maximum time, in seconds, between datatransfers to the server.) A default of 0 seconds is set for the maximumdata age that accumulated data can reside on the handset before beingdeleted. (A value of 0 means that the data will never be deleted.) Amaximum collected data byte count may be set (i.e., the maximum handsetstorage space that can be used for collected data.) A maximum collecteddata byte count is set in the admin fileset on a per-device type basiswith a value deemed reasonable for the device. Devices with limitedstorage space have a smaller maximum. The client obtains the maximumcollect byte count configuration value from the admin fileset, with thevalues determined on a carrier-by-carrier basis. The currentconfiguration is requested the first time the client connects to theserver.

Configuration values retrieved from the server include sample rate(Config-1), transmission interval (Config-2), maximum data age(Config-3) and maximum probe upload count (Config-18). Once retrievedfrom the server, these values become the new default value, even acrossclient sessions. The client tries to retrieve the current configurationvalues at most once per client session. The client applies theconfiguration values from the server immediately. For example, if themax data age is decreased, the client immediately deletes data that isthen considered stale.

In response to each probe data upload, the server sends the followingsettings to the client: sample rate (Config-1), transmission interval(Config-2), maximum data age (Config-3) and maximum probe upload count(Config-18). The client uses the collection sample rate and transmissioninterval from the server response for the remainder of thenavigation/follow me map session, or until new values are received. If anavigation session is paused, it is considered to be ended for thepurpose of traffic probes. If a navigation session is resumed, thesession collection and upload configuration values are used until newvalues are received in an upload reply.

The client does not cache the collection sample rate and transmissioninterval from the server response. There is a separate “data density”interval for each traffic provider that defines the apparent collectioninterval for that vendor. The data density intervals have a commonfactor greater than 1. The client data collection interval is thegreatest common factor of the data density intervals.

The client collects valid GPS fixes at set intervals during a navigationsession, and during a Follow Me Map session. The client considers a GPSfix as valid if both the latitude and longitude values are marked asvalid by the GPS subsystem, and represent a non-(0,0) location. Theclient does not collect fixes that are not valid. The client does notcorrelate fix information with navigation road segment information. Theclient stores the GPS timestamp, latitude, longitude, speed, heading andaccuracy. These are the standard GPS fix values. The client does notstore any other GPS information, or collected data in non-volatilestorage. The client uploads collected data to the server whenever amessage is already being sent to the server or when the maximumtransmission interval is reached. The client uploads collected data tothe server prior to the arrival maneuver announcement in a navigationsession. The client uploads collected data when a navigation session isended or paused. The client uploads collected data to the server when aFollow Me Map session is ended.

The client does not display a wait screen when uploading collectedinformation. The client deletes all uploaded information when the serverreturns a success code.

The client packs the collected data before storing it on the handset.The client uploads all collected data to the server, and has a maximumnumber of probes that can be uploaded at one time. The client attemptsto upload collected data three times at each interval, and has a maximumcollected data bundle count. The client purges collected data prior toupload, if necessary. This might happen if the data was collected in aprior application session and now exceeds the max-data-age, or when themax-data-age value is reduced. If the maximum number of bytes stored isreached, the oldest probes are deleted as needed to make room for thenew probes. Any probes with timestamps older than the maximum data ageare deleted. out-of-date data is purged at least once per minute. The“Master Clear” function deletes all collected data from non-volatilestorage. A unique identifier is assigned to each group of data probesfrom the same navigation or Follow Me session, e.g., the timestamp ofthe start of the navigation session.

The server stores all uploaded client data. A unique identifier isassigned to each group of data probes from the same navigation or FollowMe session, e.g., the session ID from the client in addition to the userstring (not MDN). Each data bundle is stored with the unique identifier,the UTC upload time, and the initial GPS time from the bundle. Theserver stores uploaded probe data for at least 30 days, and may backupor archive saved probe data before purging. The server sends probe datato the traffic partner as required, and unpacks the probe data receivedfrom the client. The server formats the data as required and transfersit to the traffic partners (such as NAVTEQ, NIM Traffic Team, etc.) Theserver doesn't send identifying information such as the MDN to thetraffic partner.

The server also stores a Traffic Probes user agreement, and enables auser to agree or decline the terms of the agreement. The server sendsthe agreement and key text to the user in the form of a MOTD requiringconfirmation, and stores the result of the client confirmation in adatabase.

Because the client sends the collected data whenever other messages arebeing sent to the server, it is possible that the server will send datato the NAVTEQ service more often than every 15 minutes for a givenhandset. No more than 1000 probes are sent per message, and messages arenot sent more frequently than every 10 seconds.

The server is capable of handling near 100% participation rate probedata, thus for all navigation sessions. As an example sizing, presume apeak hour of 137,377 navigation sessions. The average navigation sessionlasts at least 20 minutes, which translates to 80 probes sent in 2queries. Thus, the system is sized to support 77 TPS for probe querieswith the expectation of about 3000 probes per second. Further sizing forgrowth out, e.g., 6 months, the system would be sized to support 115 TPSand 4500 probes per second,

Each probe is packed on the client into 12 bytes. Ignoring therelatively small headers and other settings, the system handles sending53 KB of probe data OTA each second.

The server uses an event monitoring database to record queries receivedfrom the client as well as information sent to third parties. Thisinformation may be used to generate monthly or other reports.

In the given embodiments and exemplary sizing, the system expects 53 KBper second of GPS probe data to be send OTA from the client to server.The NAVTEQ SOAP request is approximately 550 bytes per GPS fix, so theconnection between the traffic server and the NAVTEQ web service expects2.4 MB per second.

Preferably client preferences for traffic probes are fully localized.The server is able to store localized agreements and button text, inUTF-8 encoding, to be retrieved by the client language specified in an“ident” packet.

The Traffic Probes user preferences use a Profile servlet, and the dataitself is sent as a new analytics event.

FIG. 80 shows traffic probe and related components, in accordance withthe principles of the present invention.

One goal of Traffic Probe services include the ability to determine theseverity of stop and go traffic. Because fix data is collected at “long”intervals, it is possible for each fix to have a non-zero speed, evenwhen much of the interval is spent at a dead stop. Inferences abouttraffic flow are made by comparing the speed and relative positions ofsuccessive fixes. It is possible that the collection interval may vary.

FIG. 81 shows exemplary call flows when the application starts up andrequests initial settings from the server, in accordance with theprinciples of the present invention.

In particular, as shown in step 1 of FIG. 81 showing initialization, theapplication starts up.

In step 2 showing analytics-events-query with want-config, configurationinformation is requested from analytics-events servlet without sendingany events.

In step 3 showing analytics-events-reply, configuration settings arereturned.

FIG. 82 shows exemplary call flow when the client requests MOTDs, andprobes the EULA for collecting probe data, in accordance with theprinciples of the present invention. The user's response is stored inthe same way as other EULA responses.

In particular, step 1 of FIG. 82 shows a request for messages of the day(MOTD.)

In step 2 showing message-query, the client requests messages-of-the-day(MOTDs).

In step 3 showing getUserMessages, messages are requested from thedatabase.

In step 4 showing current messages, current MOTDs are returned from thedatabase.

In step 5 showing message-reply, the messages are returned to theclient.

In step 6, a Probes EULA message is displayed to the user.

In step 7, a user accepts/declines Probes EULA.

In step 8 showing message-confirm-query, the user's response is sent tothe server for storage.

In step 9 showing confirmUserMessage, the user's response is saved intothe UserDB.

In step 10 showing message-confirm-reply, confirmation is sent that thesetting has been stored.

FIG. 83 shows exemplary call flows relevant to the use of UserPreferences to change the accept/decline status of the Probes EULA, inaccordance with the principles of the present invention.

In particular, in step 1 of FIG. 83 the user enters the preferencesscreen.

In step 2 showing profile-query, the client requests the current valueof the Probes EULA for the user.

In step 3 showing getConfirmedUserMessage, the value is requested fromthe UserDB.

In step 4 showing Probes EULA value, the value is returned.

In step 5 showing profile-reply, the value is returned to the client.

In step 6, the current setting is displayed to the user.

In step 7, the user accepts/declines Probes EULA.

In step 8 showing profile-query, the user's response is sent to theserver for storage.

In step 9 showing confirmUserMessage, the user's response is saved intothe UserDB.

In step 10 showing profile-reply, confirmation is made that the settinghas been stored.

FIG. 84 shows exemplary call flows relevant to GPS probe data collectedby the client which periodically sends it to the server for distributionto the various data collectors.

In particular, step 1 of FIG. 84 shows a request for a GPS fix.

Step 2 shows a GPS fix.

Step 3 shows an update position.

In step 4 showing Every 15 sec for 15 min, GPS fixes are continued to begathered. The actual times will vary depending on the sample rate andtransmission interval settings.

In step 5 showing analytics-events-query, the collection of GPS fixesare sent to the server in a gps-probes-event.

In step 6 showing queue event, gps-probes-event data is added on to thequeue for the analytics-dispatcher service.

In step 7 showing analytics-events-reply, a response is sent to theclient including the current sample rate.

In step 8 showing store_data, the service stores the data local to theservice provider.

In step 9 showing probeSamples, the service sends the GPS fixes to thetraffic server.

In step 10 showing queue event, the analytics-dispatcher service queuesthe gps data for the navteq-traffic service. This second servicethrottles the data flow for the NAVTEQ web server.

In step 11 showing sendProbeData, the GPS fixes are sent to the Navteqtraffic server.

In the user preferences, the user may change whether they accept GPSProbes being sent. The client queries the server to confirm that thevalue has not been changed via the web (for when the web access isimplemented). If the user changes the setting, the client sends the newsetting to the server for storage. TPS protocol is the existing profileTPS protocol with a new setting, probes-EULA, added.

A message/message confirm—Probe EULA component sends the Probes EULA tothe client, and stores the user's response in the database.

Carousel

The carousel feature of the personal wireless navigation systemdiscloses display of real time content in a carousel section of theheads-up display for ABN v5.

The carousel provides useful information about popular content thatusers regularly query. This proactive nature of the carousel and headsup display makes ABN v5 more ‘sticky’ to users who might otherwisechurn, as they might not invest time to learn how the same informationcould be ascertained by clicking through menus and options.

The carousel in ABN v5 lists various content, which rotates in thecarousel in a circular fashion, including: local weather, local gasprices, local movies, product tips, and local events. Additionalinformation to display in the carousel includes commuter traffic alerts,local traffic alerts & advisories, next meeting alert (time & place),flight status, partner defined events, and coupons from advertisers.

FIG. 85 shows an exemplary “U R Here!” area of a Heads-Up display, inaccordance with the principles of the present invention.

In particular, as shown in FIG. 85, the “U R Here!” area of the Heads-Updisplay informs a person of his/her current location, by reversegeocoding their location to at least a pair of ‘City, State’, etc. Theaccuracy and type of service is used to decide whether to show “Street,City, State, Zip code” string, or just “City, State”. Since the locationmay be acquired using other services besides GPS which are lessaccurate, there is no need to include a street name or number associatedwith the reverse geo-coded location. Plus if the person is using theproduct in a dense metropolitan area, the urban canyon effect impactsthe reported latitude and longitude by the GPS signal. Country need notbe shown unless it changes from the previous time displayed.

A ‘Map’ button allows the user to switch from Heads-Up display to ‘Map’mode. An ‘Update’ button allows the user to manually request updatedcontent for the entire Heads-up display. Next to the button there is asmall indicator that displays the last time the content was updated. Thebottom left of the “U R Here!” displays the text ° Roaming′ every timethe application is in data roaming mode. This let's the user decidewhether they want to press the ‘Update’ button or not.

FIG. 86 shows an exemplary “Real-time Content Carousel” area of aHeads-Up display, in accordance with the principles of the presentinvention.

In particular, as shown in FIG. 86, the “Real-time Content Carousel”area of the Heads-Up display provides each person with location realtime location relevant contents around his/her current area. TheCarousel displays different real time local contents. Each contentscreen displays for a period of 5 seconds. Preferably this displayperiod is configurable (though preferably not by the user).

There are exceptions for when the Carousel is not displayed as part ofthe Heads-Up display, where only ‘U R here!’ and Command buttons aredisplayed. For instance, the Carousel may not be displayed on deviceswith very small screen size. Also, for devices with orientation support(landscape and portrait modes), if the carousel cannot be displayed inlandscape mode, it is not displayed in the portrait mode either.

FIG. 87 shows an exemplary “Commands” area of a Heads-Up display, inaccordance with the principles of the present invention.

In particular, as shown in FIG. 87,

The “Commands” area of the Heads-Up display comprises three startingplaces for the user who needs to use the application to Find a POI,movie, or event; Share an existing place, or Go to a new or existingdestination.

The graphics for the “Command” buttons are intuitive, i.e. can standalone without text pairing, to accommodate the situation where sometranslated text would not otherwise fit properly inside the button.

FIG. 88 shows exemplary alternative display modes, in accordance withthe principles of the present invention.

In particular, as shown in FIG. 88, in the Heads-Up display of ABN v5,‘Map’ and ‘Speak’ are presented as alternative display modes and not‘Commands’.

Each screen displays real time content once a location has beenacquired. Rules for when and how (frequency) the ‘location’ is updated(background) and the respective location related contents and elementsare refreshed (foreground) are as follows:

While ABN v5 is obtaining an updated location fix, it continues showingthe most recent content for the most recent location fix. This includeswhen the device is roaming, and when the data network coverage has beenlost. It also includes a distinct ‘location’ indicator on the Heads-Updisplay to notify the user if ‘location’ cannot be acquired.

If ABN v5 is unable to find real time information for each content, thecarousel skips that specific content screen, until real time data hasbeen downloaded and processed for display. The carousel does not displayany content screen with blanks.

For the initial start of the application when four default contentscreens are displayed, but the data to display weather, gas prices, andmovies has not yet been downloaded, the ‘Tip’ screen is the firstcontent screen displayed to the user, and the content screens for eachof the other 3 default screens display a general ‘downloadinginformation’ message.

All content in different areas of the Heads-up display are properlylocalized, based on what each user selected in the regional settings. Ifthe user returns to the Heads-up display from another mode, or afterfinishing with a route or search, the Carousel displays the weathercontent screen.

ABN v5 updates the location in the background and Heads-Up displayrefreshes the location related contents in the foreground. If ABN v5 isidle in the Heads-up display mode, Map Mode, or ASR Mode, or any otherpart of the application (e.g., recent searches menu, POI category list)such that no LBS requests have been sent to the server, then ABN v5requests location every 20 minutes. This applies to both cases where ABNv5 is running in the foreground or background, as these are common casesin the smart phones.

If the newly acquired location is more than 5 miles apart from the mostrecent location, then ABN v5 obtains updated content and elements, thelocation of the ‘U R Here!’ is refreshed instantly on the Heads-Updisplay. Also, all the content in the carousel is updated—the currentcontent screen in the carousel can be refreshed after the next cycle.

If the user returns to the Heads-up display after a number of functions,the content of the Heads Up display is refreshed. These functionsinclude returning from a Navigation session, or from a Follow Me Mapsession. Also if the user put ABN v5 in the background (idle) to reademail, or play music, and then brought it back to the foreground. Alsoif the Heads-Up display comes back to the foreground, after the userfinishes a phone call.

Preferably local weather, local gas prices, local movies, and producttips are displayed as default content in a Carousel. The Carousel setupscreen is configurable, and thus some implementations of the wirelessnavigation device may exclude certain content from the Carousel. Forexample, no support for Events is available in Austria.

Similarly, the default set is configurable as well.

The content for the Carousel and the list in the Carousel setup screenis upgradable via a file set update. In this way a distinct version ofABN v5 may be deployed in a given market without certain contentdisplayed in the Carousel, e.g., without Gas Prices as a selectablecontent.

Each user can go to the ‘Carousel setup screen’ via ‘Preferences’, andselect a different list of content to rotate in the Carousel. Whateverthe user selects is ‘sticky’.

FIG. 89 shows an exemplary Carousel setup screen, in accordance with theprinciples of the present invention.

In particular, as shown in the exemplary embodiment of FIG. 89, ‘LocalWeather’ is the only content that is always displayed, and the usercannot deselect it. This assures that there is always real time contentin the carousel. If ‘Local Weather’ is the only content, and the userhas explicitly deselected all other content from being displayed, thenthe left and right arrows are not displayed, when ‘Local Weather’ isdisplayed, meaning the carousel does not spin.

If a user selects a content screen by touching it (or pressing CSK/OK onnon-touch devices), the personal wireless navigation system proceeds toa landing area off the relevant content screen. For instance:

‘Weather Content Screen’→‘Weather Search Results’

‘Gas Prices Content Screen’→‘POI Search Results’

‘Local Movies Content Screen’→‘Now Playing Results’

Local Events—→‘Events Near Me Results’

Product Tip Screens are not selectable or clickable. In the exemplaryembodiments there is no landing area for this content type.

There is a set display time per screen for each content type. Afterthat, the screen displays the next content screen in the Carousel. Thedisplay time per content type is an adjustable value and configurable.This time value is preferably not adjustable by the end user.

The content screen for ‘Local Weather’ displays current temperature,high and low temperatures for the current day, a graphicalrepresentation of current conditions, and high and low temperatures forthe next 3 days. The default unit of measure is set per brand of thepersonal wireless navigation system, and can be changed from Fahrenheitto Celsius and vice versa, via the regional settings under‘Preferences’. If a user clicks on the weather content screen (or bypressing CSK/OK on non-touch devices), the personal wireless navigationsystem displays the ‘Weather Search Results Screen’, This content isproperly localized when a user selects a suitable regional setting.

If the user returns to the Heads-Up display from another mode (Map modeor ASR mode), or after finishing with a route or search, the Carouseldisplays the weather content screen.

The personal wireless navigation system displays local weatherinformation of the most recent location in the Carousel (foreground),until the location has been updated in the background and updated dataacquired from the server.

The content screen for ‘Local Gas Prices’ displays: Average local priceof regular unleaded gasoline; gas station with the lowest price forregular unleaded gasoline; and the closest gas station where the lowestprice for regular gas is available. For example:

-   -   Average: $2.49    -   Lowest: $2.39    -   Shell 1.5 mi $2.59

If the closest gas station and the gas station with the lowest price arethe same station, it is listed twice, once under ‘Lowest’, and alsounder ‘Closest’. If a user clicks on the gas station content screen (orpresses CSK/OK on non-touch devices), the personal wireless navigationsystem displays a ‘Search Results Screen’. This content is properlylocalized, when users select different regional settings. For thiscontent, the display of distance matches the regional settings. Thepersonal wireless navigation system displays local gas prices andstations around the most recent location in the Carousel (foreground),until the location is updated in the background and updated dataacquired from the server.

The content screen for ‘Local Movies’ lists the three most popularmovies in the local area. This is the same rule that is used fordisplaying a list of movies when a user selects ‘Now Playing’.

For some tiers with large screens, the list may include up to 5 moviesthat are ‘Now Playing’.

Now Playing <Title 1> MPAA star rating <Title 2> MPAA star rating <Title3> MPAA star rating

Preferably each movie listing includes the rating, if available.

If a user clicks on the local movie content screen (or presses CSK/OK onnon-touch devices), the personal wireless navigation system displays the‘Search Results Screen’. The local movies around the most recentlocation are displayed in the Carousel (foreground), until the locationis updated in the background and updated data is acquired from theserver.

The content screen for ‘Product Tips’ displays quick tips on how to usecertain functions of the personal wireless navigation system, includingthe ability to setup and modify the contents of the Carousel. Preferablythere is a finite set of product quick tips, with the ability to updatethis finite set periodically, e.g., via a file set update per releasedbranded versions of the personal wireless navigation system.

The description text within each tip fits inside the content screen ofthe Carousel such that no scrolling up and down is required. Once thefirst product tip is displayed in the Carousel, it is not displayedagain until all the other product tips in the set have been displayed.After that the sequence shall resume, as illustrated in FIG. 90.

The content screen for each ‘Local Event Type’ displays the threeclosest event types starting with the current day. The format fordisplaying the each event is as follows:

<Event TYPE 1> <Event name 1> <d d> mi <Event name 2> <d d> mi <Eventname 3> <d d> mi

The syntax for displaying <next day> is the first three letters of theday of the week. If there are more than three events of the same type inthe current day, the personal wireless navigation system lists the threewhose venue are the closest. If there is only one listing in the currentday for that event type, additional events of the same type that willoccur in the next two days are listed.

If an event listing is shown at multiple times on the same day, it willbe listed up to three times, unless there are other event listings ofthe same type in that day. This content is properly localized when usersselect different regional settings. If an event listing is shown formultiple days (including the current day) it will be listed up to threetimes, if there are no other events of that type occurring sooner.

If a user clicks on the gas station content screen (or presses on CSK/OKon non-touch devices), the ‘Search Results Screen’ is displayed. Thiscontent is properly localized, as indicated by the user's configureddifferent regional settings. For this content, the display of the showdates and times matches the regional settings.

The local events around the most recent location in the Carousel(foreground) are displayed until the location is updated in thebackground and updated data is acquired from the server.

Content types such as alerts require a user to define and setup thecriteria that the Carousel uses to display the content. When the usergoes to the screen to select such content types, the personal wirelessnavigation system leads them to (

) the screen to define or modify the criteria. In addition, the Carouselsetup screen provides the ability for users to define the time windowfor when the Carousel displays certain contents in the Carousel. Forexample, for movies and events, the user is able to drill down (

) and select “Show on Weeknights and Weekends Only” or “Always Show”.

FIG. 91 shows an exemplary Carousel Setup Screen enabling users to addadditional content in the Carousel, in accordance with the principles ofthe present invention.

The content screen for Commuter Traffic Alerts displays all trafficalerts along the user's commute route. The personal wireless navigationsystem provides a set up screen to define the commute route and thewindow of time when the user wishes to know about the alert. The‘Commuter Traffic Alert’ content screen is only displayed in therelevant time window (which is set up by the user including the days ofthe week that the user cares to know about the traffic around thecommute.) The ‘Commuter Traffic Alert’ content screen can be set up forone location, most typically the user's ‘Home’ area. When the user istraveling outside the Home area, this content is not displayed in theCarousel.

The content screen for Local Traffic Alerts & Advisories displays localtraffic reports for incidents and congestion. This is similar to displayof local traffic incidents and congestions near the user's currentlocation. The Carousel lists the three closest incident/congestionsreports regardless of severity.

FIG. 92 illustrates an exemplary model for displaying this content type,which is properly localized in accordance with the user's regionalsettings. The local traffic displays around the most recent location inthe Carousel (foreground), until the location is updated in thebackground and updated data is acquired from the server.

If there are no traffic incident reports available in the local area,this content screen is not displayed (no screen with blank rows).

If a user clicks on the traffic alerts content screen (or presses on theCSK/OK on non-touch devices), the ‘Map Traffic Incidents’ is displayed.

FIG. 93 shows an exemplary content screen displaying the name andlocation of the upcoming Next Meeting Alert (Time & Place) event that ison the user's calendar, such that the user can invoke an LBS action suchas ‘Go’, ‘Find’, ‘Share’, or ‘Map’.

The personal wireless navigation system provides a set up screen for theuser to import calendar events such as a meeting that have location,from the device's Calendar to the navigation application. Calendarcontent is properly localizad when a user selects the relevant regionalsettings.

The content screen displays the status of a flight (Flight Status) thatthe user has set up to be tracked in the personal wireless navigationsystem. To display the Flight Status, a set up screen is provided forthe user to import flight information either manually, or via anotherservice. Flight Status is properly localizad when a user selects therelevant regional setting(s).

The content screen displays partner defined upcoming events that aresponsored by, or on behalf of, a Business partner (e.g., Verizon, UScellular, etc.) Upcoming partner defined events are properly localizadwhen a user selects the relevant regional setting(s).

The content screen may also display Coupons from Advertisers. Inparticular, the content screen displays a coupon advertisement fromlocal advertisers, or advertisers having a nearby POI to the currentlocation of the personal wireless navigation system.

POI Customization

A POI customization capability is provided for VZ Navigator V5. Inaccordance with this aspect of the invention, custom POIs are maintainedon the client side, not on a NIM server. This puts the onus of keepinguser lists with the organizations themselves.

There are three elements to the solution:

Defining/maintaining an “enterprise” capability for business users;

Client handset code that accepts a new type of place message, stores anduses them; and

Providing the information when a query is received.

For some time a market need has existed to support custom POIs. CustomPOIs enable some users to easily select businesses and other locationsthat, in general, are not as easily accessible to others. In someinstances, custom POIs may refer to location names that are notavailable at all through other services. This has been challengingbecause of several specific issues, described below. The challenge is toprovide POIs only to those entitled to or with an expressed interest inspecific POIs.

VX Navigator v5 provides an enterprise administrator with the ability toprovision an enterprise user MDN list to access the enterprise POIs. Theability to manage (i.e., add/update/delete) enterprise specific POIs forenterprise employees usage is also provided, as is the ability toperform local search on POIs that are specific to the enterprise. Localsearch on enterprise related POIs from VZ Navigator V5.0 Website &application are enabled to enterprise users whose MDNs have beenprovisioned on the enterprise MDN list.

The challenge of managing custom POIs for enterprise or special interestgroup use involves four specific requirements: ensuring location“validity”; defining a way to collect new POI information quickly andautomatically from third parties; An ability to present specific POIsand to handle conflicting information from different databases withsimilar, sometimes overlapping information—Example: Gas stations fromNAVTEQ, and gas stations from OPIS; and Presenting custom POIs only tousers who are entitled to them, or alternatively, have expressedinterest in seeing additional POIs.

The present invention ensures that a location is “valid”; manages thevarious POIs that each application user is entitled to view; andprovides a way to alert a defined user that a custom POI option isavailable. Custom POIs are presented only to users who are eitherentitled to see them (enterprise POIs), or those with a specificinterest using a solution that is client-based, not centrally managed ona NIM-hosted service.

The following sections describe how a service offering thesecapabilities works, which investigate each of four challenges: Managingcustom POI locations; Resolving POI conflicts; Managing custom POIusers; and User flexibility for handling custom POIs.

As noted earlier, challenges in this area include defining an“enterprise” partner, and accommodating changes to the listed locations.

At a minimum, several items are provided to an “enterprise” customer,who in turn must ensure adherence to some standards.

A new enterprise partner must permit submission validation, ensuringthat field definitions agree with content; and address “validation”.

Requirements for supporting updates to the enterprise location list arebased on the “volatility” of the list. Most lists are unlikely to changefor many weeks/months. This relates to business locations, while othersmay have many locations and are hence likely to be updated morefrequently. Within the invention it is also possible for the list tochange on a minute by minute basis—An example is a list of locationsthat require a site visit (route based on deliveries, requests forpick-up).

Preferably enterprise administrators define categories of locations.Establishment of a service requires a service “template” that includesthe “Enterprise ID”, core field, and location information.

The “Enterprise ID” preferably includes: The name of the “enterprise”;and the number and names of sub-category fields that the enterprisecommits to support.

Core field options include:

-   -   Enterprise ID (assigned automatically with acceptance of        enterprise)    -   Enterprise name (Required)—This is the level 1 (top level name)        presented for the user to select—(This is the default if no        level 2) Location types (Optional Level 2)—Must agree with        definition set.

Location Information includes:

-   -   Location name (Optional) (Example “Central States Office”)    -   Street address 1 (Required)    -   Street address 2 (Optional)    -   City (Required)    -   State/province (Required)    -   Postal/zip code (Required)    -   Country (Optional)    -   Phone number (Optional)    -   Lat/Lon (Optional)

The absence of a country code causes the system to default to localcountry.

The preferred periodicities of which when new information is suppliedinclude: once a day; once a week (preferred); once a month; Annual; andonce.

Location list submission supports list updates as frequently as once aday though initially weekly system updates are suitable. The initialrequirement is for one update/week, which may be combined with any otherupdates. Complete list replacement is acceptable as the ONLY model forlist updates initially. An option to add a new address incrementally ispreferred. Not required is the option to delete an existing addressexcept through complete list replacement.

The geo-code of each address is supplied through a defined updateprocess. A response is provided to the originator listing the originaladdress, and providing any information available on the failure (e.g.,“invalid street address”). Suitable error messages are provided forlikely/possible issues detected in the process (feed issues, etc.)

The requirement is based on defining “valid” locations. Validity in thiscase means that an address can be geo-coded. It does not mean that thelocation is “correct”.

Additional explanation of location types: The category listings supportsone “category” or “sub-category” per location: “Company” (default,Category A); or “Sub-categories” (example: “Sales Offices”, Category B).

It is possible to define the same location multiple times to supportmultiple category listings. (In the following examples, the first fieldhas “level” (Category A is “all locations”), the second is the name ofthe office, the third, is the first line of a street address, the fourthcould be a suite # (address line 2), etc.

An example with no location name:

“A” 123 Main Street “Dayton, Ohio, 43210, 513-640-4120”

“B” 123 Main Street “Dayton, Ohio, 43210, 513-640-4000”

An example with named locations:

“B, Southern Ohio Region, 123 Main Street “Dayton, Ohio, 43210,513-640-4120”

“A, District Sales Office, 123 Main Street, Dayton, Ohio, 43210,513-640-4000”

An administrator is permitted to change the “my company” definition, butpreferably only in areas that do not impact client side functionality(enterprise name, sub-category names). For example, a sales office mighthave a different name.

Moreover, some changes cannot be made without changing the place messagedefinition. These require updates to the definition of what can besearched (on the mobile). Examples of changes that cannot be“incremental”: adding a new “sub-category” (example—“distributioncenters”); or changing the company name.

A user notification service, as part of an enterprise program, providesa new category of place messaging, referred to as “Custom POI PlaceMessage” that provides the following capabilities:

A web interface enables the designated enterprise administrator to sendthe Custom POI Place Message to one or multiple MDNs. The interface isprotected by an ID/password that must be unique for each enterprise.

Two “options” are available through the interface for the Custom POImessage: Establish/Update Custom POI categories—New “Custom POI” messageto establish custom category and any required sub-categories (DEFAULT);and a Remove Custom POI option to delete a category and anysub-categories. Each of the categories relies on an “invisible ID” toensure that the right POIs are impacted. The ID is managed by themanufacturer when the account is created, and preferably remains withthe account.

The Custom POI Place Message is created by the enterprise administrator,and is maintained on a manufacturer server. The Custom POI

Place Message is accessible from a web-based interface. The Custom POIPlace Message preferably includes, at a minimum: Enterprise ID (notdisplayed); Enterprise display name; Enterprise category(ies) (asneeded); Purpose; and accompanying message, which may be limited. Theenterprise ID is essential to ensure the user's ability to reference theappropriate location list.

FIGS. 94A-94C show an exemplary web interface Mock-up, in accordancewith the principles of the present invention.

In particular, FIG. 94A shows an exemplary Login; FIG. 94B shows anexemplary interface to send a message; and FIG. 940 shows an exemplarypage defining support for company name and optional sub-categories.

FIG. 95 shows exemplary support for Enterprise definition, in accordancewith the principles of the present invention.

FIG. 96 shows presentation of Custom POIs to eligible/interested users,in accordance with the principles of the present invention. There aretwo classes of users (enterprise, special interest), but both are likelyto require similar approaches to resolving custom POIs. These needs arelikely to occur in user reception options, when using custom POIs,and/or when deleting/restoring custom POIs.

The following define user options for receiving a “POI category” placemessage. A POI category place message functions similarly to today'splace messages with automatic invocation of the application. A receivinguser has the option to: (1) Accept the request to automaticallyincorporate the defined POI options (category and sub-category), Thismay include either a new or modified category list. (2) Postpone adecision on whether to incorporate the new POI list. (3) Refuse toincorporate the POI category(ies). (4) The option to reply to thereceiving message may be suspended. Thus, a new category listing may beadded, a category listing may be updated, and/or a category listing maybe removed.

FIG. 97 depicts a device screen for a user to select enterprise orinterest-specific POIs as a specific Category (SEARCH>CATEGORY), inaccordance with the principles of the present invention.

The location for a single enterprise category is preferably the secondposition in the category listing. If the user receives and acceptsmultiple custom POIs messages (different enterprises) they arepreferably presented in the following order: The most recent custom POIcategory accepted by the user is presented at the second position (below“All Categories”). If the user accepts an additional customer POIcategory message, it displaces the earlier category which will then bepresented in the third position. As categories are added, olderselections are “pushed down”.

If sub-categories are available, a right arrow (

) at the right-most point of the column indicates the option. Thisfunctions as today's “eating & drinking” option, meaning that if the“main category” is selected, all locations in the category arepresented. If a “sub-category” is selected, only locations meeting thiscriterion are selected. If no sub-categories are designated, thecategory offers no “right arrow” option.

Users have two options to delete category listings for custom POIs:“Delete a custom category” (which will delete all sub-categories); anddelete ALL custom categories (if there are multiple ones). Users do nothave the option to delete “sub-category” listings (e.g., “salesoffices”).

In operation, delete custom categories are an option on theSEARCH>CATEGORY screen. If NO custom categories are loaded on thedevice, the option may either be NOT provided at all (preferred), or“Grayed out”. The option is preferably not “actionable” if no customPOIs are available. If user selects the option to delete, they arepresented with a new screen listing of any custom categories on a listin the same order as they appear on the displayed screen (LIFO). Thecursor highlights the top entry but is scrollable to any other customPOI category entry. The CSK for the screen is “Delete” for the DeleteCustom Category screen. Sub-categories need not be displayed. If the“Delete” option is selected, a “confirm delete” message is presented. Ifthe user fails to confirm the deletion, the category listing ispreserved.

Search Options and Resolution of POI Conflicts.

Location information supplied by the enterprise partner is preferablynot added to a general search database. Thus, a search from subscriberswho do not have the Custom POI category should not be enabled to locatethis information, though this preferably does not preclude others fromfinding the “equivalent” location from a standard database. (Businessoffices may be listed in a standard data feed). The custom POI categorytakes precedence over other factors. For instance, if a user selects acustom POI category, no results other than those in the custom POIcategory are returned.

“Combined” searches may be supported. For instance, a user may combine a“What” with a special POI category. Similarly, a user may change theorigin for the search. All returned results are from within a setdefined by the Custom Category.

FIG. 98 shows that in this way the inventive navigation product avoidspotential problems of multiple duplicate listings by providing a“binary” selection capability that does not merge existing/other POIswith enterprise or interest-specific POIs.

There are two broadly defined types of users: Enterprise users, and“special interest” users.

Enterprise users are those that are either employed by, or worthwith/for a company that subscribes to an enterprise version of anwireless navigation device (e.g., AtlasBook Navigator v5) or relatedproduct. In either event, their identifying information is known to an“administrator” of the company who has the option to send a special“Custom POI” place message. If the place message is not successfullytransmitted/received, the administrator would receive a reportexplaining the issue.

When the message is received, the user may or may not accept themessage. If the user elects to do so, the message activates thenavigation service and is provided the option to add the POI categoryoption(s) indicated (or not). If the option is not immediately added,the message may still be stored, and activated later. Once the categorymessage is “accepted”, the user may immediately use the capability.

In operation, when the user selects “Local Search”, and then “MyCompany” inside the “Category” box, all searches apply to “My Company”locations. If the “My Company” option incorporates additional options,these are presented for selection at any time. If no sub-option isselected, then all relevant company locations are delivered.

Special Interest User Scenario works best with “automated” processing ofinitial custom POI place messages, essentially eliminating thegatekeeper function (sending “activation” messages) provided by theadministrator in the enterprise scenario. In this option, a userinterested in “subscribing” to a list of locations that may be veryspecialized (example: Geo-cache enthusiasts), goes to a website. At thewebsite, the user registers to have access to the “list” and receiveseither a directed

SMS, or some other link for activating the service. Then, thereception/acceptance process is as otherwise shown and described above.

While the invention has been described with reference to the exemplaryembodiments thereof, those skilled in the art will be able to makevarious modifications to the described embodiments of the inventionwithout departing from the true spirit and scope of the invention.

1-14. (canceled)
 15. A method of displaying a circular-depicted carouseluser interface for a personal wireless device, comprising: assembling aplurality of visual carousel pages visually into a carousel that rotatesabout a center, said plurality of visual carousel pages displayinginformation readable from a direction outside a perimeter of saidcarousel; sensing a gesture on a display of said personal wirelessdevice to rotate said carousel; and continuously rotating said carouselsequentially through said plurality of visual carousel pages such thatsaid plurality of visual carousel pages repeat in said rotation in asame order on subsequent full rotations of said carousel.
 16. A methodof displaying a circular-depicted carousel user interface for a personalwireless device according to claim 15, further comprising: updatinglocation-based information on said plurality of visual carousel pages ona subsequent full rotation of said carousel.
 17. A method of displayinga circular-depicted carousel user interface for a personal wirelessdevice according to claim 16, further comprising: said update isrepeatedly performed approximately every 20 minutes.
 18. A method ofdisplaying a circular-depicted carousel user interface for a personalwireless device according to claim 15, further comprising: periodicallyupdating a current location of said personal wireless device; andupdating at least one of said plurality of visual carousel pages basedon said periodically updated current location of said personal wirelessdevice.
 19. A method of displaying a circular-depicted carousel userinterface for a personal wireless device according to claim 18, furthercomprising: said update is repeatedly performed approximately every 20minutes.
 20. A method of displaying a circular-depicted carousel userinterface for a personal wireless device according to claim 15, furthercomprising: rotating said carousel in a clockwise or counter-clockwisedirection depending upon a pre-determined hand gesture on a touch screenof said personal wireless device.
 21. A method of displaying acircular-depicted carousel user interface for a personal wireless deviceaccording to claim 15, further comprising: updating a current locationof said personal wireless device when said carousel is operating in abackground of said personal wireless device.
 22. A method of displayinga circular-depicted carousel user interface for a personal wirelessdevice according to claim 15, wherein: said plurality of visual carouselpages include local weather based on a current location of said personalwireless device.
 23. A method of displaying a circular-depicted carouseluser interface for a personal wireless device according to claim 15,wherein: said plurality of visual carousel pages include gas prices ateach of a plurality of gas stations nearest a current location of saidpersonal wireless device.
 24. A method of displaying a circular-depictedcarousel user interface for a personal wireless device according toclaim 15, wherein: said plurality of visual carousel pages includemovies playing at at least one closest theater to a current location ofsaid personal wireless device.
 25. A method of displaying acircular-depicted carousel user interface for a personal wireless deviceaccording to claim 15, wherein: said plurality of visual carousel pagesinclude information about an upcoming event in a local region relatingto a current location of said personal wireless device.
 26. A method ofdisplaying a circular-depicted carousel user interface for a personalwireless device according to claim 15, wherein: at least one of saidplurality of visual carousel pages includes a navigation applicationrunning on said personal wireless device.
 27. A method of displaying acircular-depicted carousel user interface for a personal wireless deviceaccording to claim 15, further comprising: replacing content of at leastone of said plurality of visual carousel pages after each full 360degree rotation of said carousel.
 28. Apparatus for displaying acircular-depicted carousel user interface for a personal wirelessdevice, comprising: means for assembling a plurality of visual carouselpages visually into a carousel that rotates about a center, saidplurality of visual carousel pages displaying information readable froma direction outside a perimeter of said carousel; means for sensing agesture on a display of said personal wireless device to rotate saidcarousel; and means for continuously rotating said carousel sequentiallythrough said plurality of visual carousel pages such that said pluralityof visual carousel pages repeat in said rotation in a same order onsubsequent full rotations of said carousel.
 29. Apparatus for displayinga circular-depicted carousel user interface for a personal wirelessdevice according to claim 28, further comprising: means for updatinglocation-based information on said plurality of visual carousel pages ona subsequent full rotation of said carousel.
 30. Apparatus fordisplaying a circular-depicted carousel user interface for a personalwireless device according to claim 28, further comprising: means forperiodically updating a current location of said personal wirelessdevice; and means for updating at least one of said plurality of visualcarousel pages based on said periodically updated current location ofsaid personal wireless device.
 31. Apparatus for displaying acircular-depicted carousel user interface for a personal wireless deviceaccording to claim 28, further comprising: means for rotating saidcarousel in a clockwise or counter-clockwise direction depending upon apre-determined hand gesture on a touch screen of said personal wirelessdevice.
 32. Apparatus for displaying a circular-depicted carousel userinterface for a personal wireless device according to claim 28, wherein:at least one of said plurality of visual carousel pages includes anavigation application running on said personal wireless device. 33.Apparatus for displaying a circular-depicted carousel user interface fora personal wireless device according to claim 28, further comprising:means for replacing content of at least one of said plurality of visualcarousel pages after each full 360 degree rotation of said carousel.